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FEDERAL ENTERPRISE ARCHITECTURE: A 
BLUEPRINT FOR IMPROVED FEDERAL IT 
INVESTMENT MANAGEMENT AND CROSS- 
AGENCY COLLABORATION AND INFORMA- 
TION SHARING 


WEDNESDAY, MAY 19, 2004 

House of Representatives, 

Subcommittee on Technology, Information Policy, 
Intergovernmental Relations and the Census, 

Committee on Government Reform, 

Washington, DC. 

The subcommittee met, pursuant to notice, at 2:35 p.m., in room 
2154, Rayburn House Office Building, Hon. Adam Putnam (chair- 
man of the subcommittee) presiding. 

Present: Representatives Putnam and Clay. 

Staff present: Bob Dix, staff director; John Hambel, senior coun- 
sel; Shannon Weinberg, professional staff member and deputy 
counsel; Juliana French, clerk; Felipe Colon, fellow; Kaitlyn 
Jahrling, intern; David McMillen, minority professional staff mem- 
ber; and Cecelia Morton, minority office manager. 

Mr. Putnam. A quorum being present, this hearing of the Sub- 
committee on Technology, Information Policy, Intergovernmental 
Relations and the Census will come to order. A little bit late, but 
we are in order. I apologize for the delay; we have just finished a 
long series of votes on the House floor. 

Good afternoon and welcome to the subcommittee’s hearing enti- 
tled, “Federal Enterprise Architecture: A Blueprint for Improved 
Federal IT Investment & Cross-Agency Collaboration and Informa- 
tion Sharing.” 

The purpose of this hearing is to provide congressional oversight 
on the progress being made by the Office of Management and 
Budget and the Federal agencies to develop and implement a Fed- 
eral Enterprise Architecture. The subcommittee will also examine 
the progress, success, and continuing hurdles facing various agen- 
cies and departments in integrating their individual agency enter- 
prise architecture with the FEA initiative. 

This hearing is a continuation of the series of oversight hearings 
conducted by the subcommittee during the 108th Congress to keep 
Federal Government agencies and decisionmakers aggressively fo- 
cused on meeting the key goals of the E-Government Act of 2002: 
greater accessibility to government by citizens and businesses; im- 
proving government efficiency and productivity; enhancing cus- 
tomer service; facilitating cross-agency coordination; and tangible 

( 1 ) 
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cost savings to taxpayers through the use of 21st century tech- 
nology and proven “best practices” throughout the Federal Govern- 
ment. 

During the 1st session of the 108th Congress, this subcommittee 
focused a great deal of attention on the oversight of the Federal 
Government’s E-Government element of the President’s manage- 
ment agenda. With a commitment to an aggressive effort, the 
launch of the President’s management agenda in August 2001 es- 
tablished a strategy for transforming the Federal Government in a 
manner that produces measurable results that matter in the lives 
of the American people. 

One of the five components of the PMA is Electronic Govern- 
ment, intended to utilize the power and creativity of information 
technology to produce a more citizen-centric government, as well as 
one that is more efficient, productive, and cost-effective on behalf 
of the taxpayers. E-Government provides a platform to establish 
cross-agency collaboration and a rapid departure from a stovepipe 
approach to government operations to an approach that facilitates 
coordination, collaboration, communication, and cooperation. 

With Federal Government expenditures on IT products and serv- 
ices projected to close in on $60 billion in fiscal year 2005, the Fed- 
eral Government will be the largest IT purchaser in the world. For 
too long, and even continuing in some places today, individual 
agencies have pursued their own IT agendas that focus solely on 
mission rather than emanating from a commitment to customer 
service or sound business processes. Without a system of checks 
and balances built into the investment process to compare IT needs 
with mission goals, the potential for waste is great. 

As a first step to a meaningful coordination of IT expenditures 
governmentwide. Congress passed the Clinger-Cohen Act of 1996, 
which included the Information Technology Management Reform 
Act and the Federal Acquisition Reform Act. This legislation sets 
forth requirements for Federal Government IT investment manage- 
ment decisionmaking and corresponding responsibility. It requires 
agencies to link IT investments to agency strategic planning, in- 
cluding the linkage to an enterprise architecture. 

Under Clinger-Cohen, each individual Federal Government agen- 
cy must create and implement an enterprise architecture. An EA 
is a tool that defines the structure of any activity or mission within 
a single organization or across multiple organizations. It allows or- 
ganizations to then apply IT resources to accomplish those activi- 
ties identified. An EA also helps an organization identify the rela- 
tionships between business operations and the underlying infra- 
structure and applications that support those operations. The pur- 
pose of the development of agency EAs is to facilitate cross-agency 
analysis of the business or purpose of government and to make pos- 
sible the identification of duplicative investments, gaps, and pros- 
pects for cross-agency collaboration. The goal, as with all e-Gov ini- 
tiatives, is to make the Federal Government more efficient and cus- 
tomer-focused. 

An enterprise architecture, developed and implemented based on 
the FEA framework, is an essential tool in guiding IT investments. 
A recent GAO study reports that “that investing in IT without de- 
fining these investments in the context of an architecture often re- 
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suits in systems that are duplicative, not well integrated, and un- 
necessarily costly to maintain and interface.” 

While the utility of EAs in the Federal Government is promising, 
the progress of the Federal Government in completing the agency 
FA initiative is less than promising. In 2001 and 2003, GAO as- 
sessed the progress of agencies’ efforts to develop and implement 
EAs. In 2003, overall, GAO found the state of EA governmentwide 
is not mature, with approximately 79 percent of agencies at stage 
1 of GAO’s five-stage assessment framework and 21 percent were 
at stage 2. Only one agency, the Executive Office of the President, 
reached stage 5, the final stage of maturity. 

The E-Government Act of 2002 makes oversight of the agencies’ 
EA efforts the responsibility of OMB’s Administrator of E-Govern- 
ment and Information Technology. As a result of a combination of 
OMB’s oversight responsibilities under the E-Gov Act of 2002 and 
the disappointing results of GAO’s 2001 governmentwide EA matu- 
rity assessment, 0MB identified a need for a common framework 
for agencies to use in facilitating the EA effort. 0MB cited the lack 
of a Federal EA as an impediment to achievement of the e-Govern- 
ment initiatives. So 0MB began work on creating the FEA in 2002. 
This effort appears to be initially successful as a tool for recogniz- 
ing commonalities and inefficiencies. 0MB used the FEA during its 
review of the agency’s 2004 budget submissions and found numer- 
ous common government functions and consequently numerous re- 
dundant efforts in spending. Out of those numerous common func- 
tions, 0MB selected five core government functions and created the 
next phase of the e-Government initiative. This new phase, called 
the Lines of Business Initiative, specifically targets duplicative ef- 
fort in spending. Despite this development, I still find cause for 
concern. According to a November 2003 GAO report, the self-re- 
ported costs by agencies in developing their individual EAs are 
close to $600 million. Those same agencies report more than $805 
million will be necessary to complete their EAs. What the vast ma- 
jority of government agencies’ EA maturity assessed at the stage 
1 level, we still have a long way to go before we fully realize the 
benefits of effective EA management. In the course of this hearing, 
my hope is that we will be able to determine the anticipated cost 
savings in light of the significant investment already made in the 
efforts to develop EAs governmentwide. 

Today’s hearing is an opportunity to examine both the progress 
and success of OMB’s FEA initiative as well as explore the obsta- 
cles faced both by agencies and departments in integrating their 
EAs into the FEA. As we have heard in previous hearings, many 
of the impediments are cultural and people-based, rather than 
being attributable to the technology itself or available resources. 
Case in point, in GAO’s 2003 assessment of governmentwide EA ef- 
forts, more agencies reported a lack of agency executive under- 
standing of EA and the scarcity of skilled architecture staff as sig- 
nificant challenges than was reported in 2001. 

I eagerly look forward to the testimony of our distinguished 
panel of leaders in various agencies in an industry who will also 
give us the opportunity to demonstrate the progress that has been 
made thus far with the FEA initiative, while acknowledging the 
magnitude of the challenge that lies ahead. 
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Today’s hearing can be viewed live via Webcast by going to re 
form. house. gov and clicking on the link “Live Committee Broad 
cast.” 

[The prepared statement of Hon. Adam H. Putnam follows:] 
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Subcommittee on Technology, Information Policy, 
Intergovernmental Relations and the Census 
Congressman Adam Putnam, Chairman 



OVERSIGHT HEARING 

STATEMENT BY ADAM PUTNAM, CHAIRMAN 


Hearing topic: ^'Federal Enterprise Architecture: A Blueprint for Improved 
Federal IT Investment & Cross-Agency Collaboration and Information Sharing.’’* 


Wednesday, May 19, 2004 
2:00 p.m. 

Room 2154, Rayburn House ODice Building 


OPENING STATEMENT 


Good afternoon and welcome to the Subcommittee’s hearing on the “Federal Enterprise 
Architecture: A Blueprint for Improved Federal IT Investment & Cross-Agency 
Collaboration and Information Sharing.” 

The purpose of this hearing is to provide Congressional oversight on the progress being 
made by the Office of Management and Budget and the federal agencies to develop and 
implement a Federal Enterprise Architecture (FEA). The Subcommittee will also closely 
examine the progress, success factors, and continuing hurdles facing various federal 
agencies and departments in integrating their individual agency enterprise architecture 
with the FEA initiative. 

This hearing is a continuation of the series of oversight hearings conducted by the 
Subcommittee during the 108'^ Congress to keep federal government agencies and 
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decision-makers aggressively focused on meeting the key goals of the E-Government Act 
of 2002: greater accessibility to government by citizens and businesses; improving 
government efficiency and productivity; enhancing customer service; facilitating cross- 
agency coordination; and tangible cost savings to taxpayers through use of 21^‘ century 
technology and proven “best practices” throughout the federal government. 

During the 1*' session of the 108*** Congress, this Subcommittee focused a great deal of 
attention on the oversight of the federal government’s E-Government element of the 
President’s Management Agenda (PMA). With a commitment to an aggressive and 
sustained effort, the launch of the President’s Management Agenda in August 2001 
established a strategy for transforming the federal government in a manner that produces 
measurable results that matter in the lives of tlK American people. 

One of the five components of the PMA is Electronic Government, intended to utilize the 
power and creativity of information technology (IT) to produce a more citizen-centric 
government, as well as one that is more efficient, productive, and cost-effective on behalf 
of the American taxpayer. E-Government provides a platform to establish cross-agency 
collaboration and a rapid departure from a stovepipe approach to government operations 
to an approach that facilitates coordination, collaboration, communication, and 
cooperation. 

With federal government expenditures on IT products and services projected to clo.se in 
on $60 billion dollars in FY05, the federal government will be the largest IT purchaser in 
the world. For too long, and even continuing in some places today, individual agencies 
have pursued their own IT agendas that focus solely on mission rather than emanating 
from a commitment to customer service or sound business processes. Without a system 
of checks and balance built into the investment process to compare IT needs with mission 
goals, the potential for waste is excessive. 

As a first step to a meaningful coordination of IT expenditures government-wide, 

Congress passed the Clinger-Cohen Act of 1996, which included the Information 
Technology Management Reform Act and the Federal Acquisition Reform Act. This 
legislation sets forth requirements for federal government IT investment management 
decision-making and corresponding responsibility and accountability. It requires 
agencies to fundamentally link IT investments to agency strategic planning, including the 
linkage to an enterprise architecture. 

Under the Clinger-Cohen Act, each individual federal government agency or department 
must create and implement an enterprise architecture (EA). An EA is a tool that defines 
the structure of any activity or mission within a single organization and across multiple 
organizations. It allows organizations to then apply IT resources to accomplish those 
activities or missions identified. An EA also helps an organization identify the 
relationships between business operations and the underlying FT infrastructure and 
applications that support those operations. The purpose of the development of agency 
EAs is to facilitate cross-agency analysis of the business or purpose of government and to 
make possible the identification of duplicative IT investments, gaps, and prospects for 
cross-agency collaboration. The goal, as with all e-Govemment initiatives, is to make the 
federal government more efficient, citizen-centric, and customer-focused, 

An EA, developed and implemented based on the FEA framework, is an essential tool in 
guiding IT investments. A recent GAO study reports “that investing in IT without 
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defining these investments in the context of an architecture often results in systems that 
are duplicative, not well integrated, and unnecessarily costly to maintain and interface.” 

While the utility of EAs in the federal government is promising, the progress of the 
federal government in completing tte agency EA initiative is less than promising. In 
2001 and 2003, GAO assessed the progress of the agencies’ efforts to develop and 
implement EAs. In 2003, overall, GAO found the slate of EA government-wide is not 
mature, with approximately 79 percent of agencies at Stage 1 of GAO’s five-stage 
assessment framework and 21 percent were at Stage 2. Only one agency, the Executive 
Office of the President, reached Stage 5, the final stage of maturity. 

The E-Government Act of 2002 makes oversight of the agencies’ EA efforts the 
responsibility of 0MB ’s Administrator of E-Govemment and Information Technology. 
As a result of a combination of OMB’s overeight responsibilities under the 
E-Govemment Act of 2002 and the disappointing results of GAO’ s 200 1 government- 
wide EA maturity assessment, OMB identified a need for a common framework for 
agencies to use in facilitating the EA effort. OMB cited the lack of a federal EA as an 
impediment to achievement of the e-Goverament initiatives. Thus, OMB began work on 
creating the FEA in 2002. This effort appears to be initially successful as a tool for 
recognizing commonalities and inefficiencies. OMB used the FEA during its review of 
the agencies’ FY 2004 budget submissions and found numerous common government 
functions and consequently numerous redundant efforts and spending. Out of those 
numerous common functions, OMB selected five core government functions and created 
the next phase of the e-Govemment initiative. This new phase, called the “Lines of 
Business” initiative, specifically targets duplicative effort and spending. Despite this 
promising development, I still find cause for concern. According to a November 2003 
GAO report, the self-reported costs by agencies in developing their individual EAs are 
close to $600 million. Those same agencies report more than $805 million will be 
necessary to complete their EAs. With the vast majority of government agencies’ EA 
maturity assessed at the Stage 1 level, we still have a long way to go before we fully 
realize the benefits of effective EA management. In the course of this hearing, my hope 
is that we will be able to determine the anticipated cost savings in light of the significant 
investment already made in the efforts to develop and implement EAs government-wide. 

Today’s hearing is an opportunity to examine both the progress and successes of OMB’s 
FEA initiative as well as explore the continuing obstacles faced both by federal agencies 
and departments in integrating their EAs into the FEA. As we have learned in previous 
hearings, many of the impediments are cultural and people-based, rather than being 
attributable to the technology itself (or even available resources). Case in point, in 
GAO’s 2003 assessment of government-wide EA efforts, more agencies reported a lack 
of agency executive understanding of EA and the scarcity of skilled architecture staff as 
significant challenges than was reported in 2001. 

I eagerly look forward to the expert testimony our distinguished panel of leaders in 
various federal agencies and in industry will provide today as well as the opportunity to 
demonstrate the progress that has been made thus far with the FEA initiative, while 
acknowledging the magnitude of the challenge that continues to lie ahead. 


if tl II //^ 
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Mr. Putnam. I want to welcome the distinguished ranking mem- 
ber from Missouri who has heen a partner in these oversight ef- 
forts, Mr. Clay. I recognize you for your opening remarks. 

Mr. Clay. Thank you, Mr. Chairman. Thank you for calling this 
hearing, and I want to thank the witnesses for appearing before us 
today. 

The implementation of enterprise architectures throughout the 
agency community has altered the methods employed by the Gov- 
ernment beyond what used to be little more than the procurement 
and maintenance of computers and software. That concept, how- 
ever, became outdated as the Government sought to integrate both 
business functions and agency goals with information technology. 
By serving as a blueprint for integration among an agency’s core 
components, enterprise architectures soon enabled an agency to im- 
prove its services by optimizing its performance. 

It did not take long for Congress to determine that such effi- 
ciency would prove beneficial in both economic and qualitative 
terms. Through legislative efforts such as the Paperwork Reduction 
Act, the Clinger-Cohen Act, and the E-Government Act, Congress 
established a framework for agencies to facilitate effective manage- 
ment of enterprise architectures governmentwide. Along with the 
efforts of the CIO Council and OMB’s Federal Enterprise Architec- 
ture Program Management Office, the Government has successfully 
laid a foundation for effective coordination among agencies for busi- 
ness operations, information flow, and IT investment management. 

I remain concerned, however, that the agency community is not 
meeting all of its obligations for effectively managing the develop- 
ment and utilization of enterprise architectures, as only half of all 
agencies are meeting such standards according to GAO. Further, 
there seems to be no improvement in the number of agencies per- 
forming a full complement of management practices for the effec- 
tive oversight of architectures. If the Federal Government is to con- 
tinue to appropriate its annual $60 billion investment in IT sys- 
tems, we must demand better implementation and management 
practices for enterprise architectures throughout the agency com- 
munity. 

I look forward to our discussion today and ask that my statement 
be submitted for the record. 

[The prepared statement of Hon. Wm. Lacy Clay follows:] 
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STATEMENT OF THE HONORABLE WM. LACY CLAY 
AT THE HEARING ON 
ENTERPRISE ARCHITECTURE 

May 19,2004 

Thank you Mr. Chairman for calling this hearing, and I 
thank the witnesses for appearing before us today. 

The implementation of enterprise architectures throughout 
the agency community has altered the methods employed by the 
government beyond what used to be little more than the 
procurement and maintenance of computers and software. That 
concept, however, became outdated as the government sought to 
integrate both business functions and agency goals with 
information technology. By serving as a blueprint for 
integration among an agency’s core components, enterprise 
architectures soon enabled an agency to improve its services by 
optimizing its performance. 

It did not take long for Congress to determine that such 
efficiency would prove beneficial in both economic and 
qualitative terms. Through legislative efforts, such as the 
Paperwork Reduction Act, the Clinger-Cohen Act, and the E- 
Govemment Act, Congress established a framework for 
agencies to facilitate effective management of enterprise 
architectures government-wide. Along with the efforts of the 
CIO Council and OMB’s Federal Enterprise Architecture 
Program Management Office, the government has successfully 
laid a foundation for effective coordination among agencies for 
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business operations, information flow, and IT investment 
management. 

I remain concerned, however, that the agency community is 
not meeting all of its obligations for effectively managing the 
development and utilization of enterprise architectures, as only 
half of all agencies are meeting such standards according to 
GAO. Further, there seems to be no improvement in the number 
of agencies performing a full complement of management 
practices for the effective oversight of architectures. If the 
federal government is to continue to appropriate its annual $60 
billion investment in IT systems, we must demand better 
implementation and management practices for enterprise 
architectures throughout the agency community. 

I look forward to our discussion today, and ask that my 
statement be submitted for the record. 
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Mr. Putnam. Without objection. 

We will move directly to the testimony. If all the witnesses and 
any of your supporting cast who will be providing you answers 
would please rise and raise your right hands for the administration 
of the oath. 

[Witnesses sworn.] 

Mr. Putnam. Note for the record that all of the witnesses re- 
sponded in the affirmative. 

I would like to recognize our first witness, Ms. Karen Evans. On 
September 3, 2003, Karen Evans was appointed by President Bush 
to be Administrator of the Office of Electronic Government and In- 
formation Technology at the Office of Management and Budget. 
Prior to joining 0MB, Ms. Evans was Chief Information Officer at 
the Department of Energy, and served as vice chairman of the CIO 
Council, the principal forum for agency CIOs to develop IT rec- 
ommendations. Prior to that she served at the Department of Jus- 
tice as Assistant and Division Director for Information System 
Management. She is a frequent guest of this subcommittee. 

We are delighted to have you. Welcome, Ms. Evans. You are rec- 
ognized for your 5-minute statement. 

STATEMENTS OF KAREN S. EVANS, ADMINISTRATOR OF E- 
GOVERNMENT AND INFORMATION TECHNOLOGY, OFFICE 
OF MANAGEMENT AND BUDGET; RANDOLPH C. HITE, DIREC- 
TOR, INFORMATION TECHNOLOGY ARCHITECTURE AND SYS- 
TEMS, U.S. GENERAL ACCOUNTING OFFICE; DANIEL MAT- 
THEWS, CHIEF INFORMATION OFFICER, DEPARTMENT OF 
TRANSPORTATION; AND KIM NELSON, CHIEF INFORMATION 
OFFICER, ENVIRONMENTAL PROTECTION AGENCY 

Ms. Evans. Good afternoon, Mr. Chairman and Ranking Member 
Clay. Thank you for inviting me to speak with you today and dis- 
cuss the administration’s Federal Enterprise Architecture Program. 

The FEA provides a strategic model and a plan to improve the 
Federal information technology investment management, create 
cross-agency collaboration, and enhance governmentwide informa- 
tion sharing. My remarks will provide an update on key enterprise 
architecture developments across the Federal Government specifi- 
cally focusing on the value of the FEA program and its support of 
individual agency FA initiatives in using IT to achieve results for 
the American citizens. 

The administration is working to ensure the Government as a 
whole and the agencies in particular integrate resource decision- 
making with discipline planning activities to yield better program 
performance in managing our IT resources and assets, and FA is 
the information asset that defines the mission program, the infor- 
mation and technologies needed to perform the mission, and the 
transitional processes for implementing new technologies when 
needs change. 

The goals of the Federal Enterprise Architecture are to enable 
the Federal Government to identify opportunities to leverage tech- 
nology and alleviate redundancy, or to highlight where agency 
overlap limits the value of information technology investments; fa- 
cilitate horizontal, cross-Federal, and vertical Federal, State, local, 
and tribal integration of IT resources; establish a direct relation- 
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ship between IT and mission program performance; and support 
citizen-centered customer-focused government to maximize IT in- 
vestments to better achieve mission outcomes. 

Whether at the Federal, agency, or program level, a mature and 
continually utilized EA helps in the management of resources by 
plainly organizing the enterprise IT assets within an understand- 
able strategic framework. This enables agency leaders to develop a 
clear road map for future investments while ensuring a more effec- 
tive IT portfolio supports the delivery of faster and better program 
performance. 

In addition to supporting agencies’ EA efforts, the Eederal Gov- 
ernment is using the EEA to identify numerous cross-agency oppor- 
tunities to cut costs and increase efficiencies through sharing com- 
mon business functions and technology applications. Specifically, 
we are enhancing the EEA to maximize the performance of the 
Eederal Government’s $60 billion IT portfolio by: identifying oppor- 
tunities to develop common solutions within Lines of Business 
[LOBs] resulting in increased government effectiveness and tax- 
payer savings; linking agency performance to strategic IT invest- 
ment decisions through agency enterprise architectures; and using 
EA-related budget requirements to ensure security and privacy 
considerations are integrated as agencies make strategic IT invest- 
ment choices. 

The EEA framework has yielded results demonstrating a new 
ability for the Eederal Government to drive collaboration and accel- 
erate consolidation of redundant activities, saving taxpayer dollars. 
One example of this is the concept of Lines of Business [LOBs], a 
functional representation of the overall business requirements of 
government. In response to our preliminary review of fiscal year 
2004 and 2005 EEA budget data, 0MB launched a governmentwide 
effort in Eebruary 2004 to analyze the first set of LOB initiatives. 
The LOB Task Eorces are now using EA-based principles and prov- 
en best practices to identify business-driven common solutions to 
transform government by breaking down traditional agency silos 
and increasing collaboration. The EEA structure and analysis are 
foundational to the LOB initiatives. This activity provides a 
glimpse of how we can use the EEA as transformational framework 
to accelerate the delivery of services and truly achieve the 21st cen- 
tury e-Government. Implementation of these LOB common solu- 
tions will begin in fiscal year 2005, leading to significant improve- 
ments in process efficiency, system interoperability, and data shar- 
ing. 

0MB has developed an EA Assessment Eramework to help agen- 
cies improve their EA programs and benefit from the results of 
using EA as a strategic planning tool. OMB’s EA Assessment 
Eramework is designed to help each agency assess the capability 
of its EA program and is intended to compliment the GAO EA 
management maturity framework which assesses the EA program 
capacity. 

The EA Assessment Eramework will be used annually by 0MB 
and the agencies to identify opportunities and facilitate the discus- 
sion of EA performance and use. This ongoing collaboration be- 
tween 0MB and the agencies removes the discussion of EA from 
the current budget cycle and allows us to engage when results can 
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be used by agencies during the development of their request in- 
stead of after the fact when they submit the information to 0MB. 

0MB continues helping agencies align their efforts with the FEA 
program, and toward this goal Federal Enterprise Architecture 
Management System [FEAMS], is ready for agencies to use for the 
fiscal year 2006 budget process. This will be the first time ever that 
agencies will be able to use this Web-based tool to look across the 
Government and identify potential collaboration partners and 
share technology components as they develop their own IT invest- 
ments. 

As part of our commitment to strengthen our agency security, 
0MB and the CIO Council are developing the FEA Security and 
Privacy Profile, an overlay to assist Federal managers in discover- 
ing early on where risk exposures exist, the potential range for con- 
trols needed to address such risks, and the potential cost of those 
controls. The FEA program is helping agencies to identify, under- 
stand, and integrate security and privacy issues in the earliest 
stages of planning and development, promoting the efficient oper- 
ation, and preventing unintended consequences which may require 
costly corrections at the end of the development. 

In short, we are looking to evolving the FEA reference models 
and further enhancing resources such as FEAMS and the EA As- 
sessment Framework for agencies. 0MB seeks to develop the Gov- 
ernment-wide practice of enterprise architecture so that agencies 
can proactively collaborate to make investment decisions prior to 
submitting their budgets to 0MB. 

In the longer term, the administration will continue to create op- 
portunities for transforming government delivery of service to the 
citizens, working to fully integrate performance measurement con- 
cepts throughout the FEA reference models to ensure agencies are 
considering outcomes in all aspects of IT portfolio planning. 

The administration will continue to collaborate with agencies and 
with Congress, State, local, and tribal governments to ensure the 
promise of the enterprise architecture is fully realized across gov- 
ernment. I look forward to working with you on these matters and 
will be happy to take questions. 

[The prepared statement of Ms. Evans follows:] 
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Mr. Chairman and Members of the Subcommittee: 

Thank you for inviting me to speak with you today to discuss the Administration’s Federal 
Enterprise Architecture (FEA) Program, 

The FEA provides a strategic model and plan to improve federal information technology (IT) 
investment management, create cross-agency collatoration, and enhance government-wide 
information sharing. My remarks will provide an update on key enterprise architecture (EA) 
developments across the federal government, specifically focusing on the value of the FEA 
Program and its support of individual agency EA initiatives in using IT to achieve results for the 
American people. 

Overview 


An objective of the Government Performance and Results Act (GPRA); the Clinger-Cohen Act; 
the E-Govemment Act of 2002; and the President’s Management Agenda (PMA) is to integrate 
resource decision-making with disciplined planning activities to yield better program 
performance. The Administration is working to ensure the government as a whole and the 
agencies in particular apply and implement this objective in managing our IT resources and 
assets. 

From this perspective, we are approaching the challenge on a dual track. First, we are focusing 
on developing a strategic framework. The goals of the Federal Enterprise Architecture are to: 

• Enable the federal government to identify opportunities to leverage technology and 
alleviate redundancy, or to highlight where agency overlap limits the value of 
information technology (IT) investments; 

• Facilitate horizontal (cross-federal) and vertical (federal, state and local) integration of IT 
resources; 

• Establish a direct relationship between IT and mission/program performance; and 

• Support citizen-centered, customer-focused govermnent to maximize IT investments to 
better achieve mission outcomes. 
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Achieving these goals ensures the government makes the most efficient application of limited 
resources to fulfill its important responsibilities and obligations to the American people. 

Second, the FEA is supporting the maturation of enterprise architecture efforts being developed 
and implemented in agencies and departments. Through the Federal Enterprise Architecture, 
agencies are able to characterize each of their IT investments by: 

• The business line the investment supports; 

• The performance the agency seeks to achieve; and 

• The components and supporting technology that comprise the investment. 

Whether at the federal, agency, or program level, a mature and continually utilized EA helps in 
the management of resources by plainly organizing the enterprise’s IT assets within an 
understandable strategic framework. This framework not only shows the current baseline of an 
organization’s IT assets, but more importantly, it enables agency leaders to develop a clear 
roadmap for future investments while ensuring a more efficient IT portfolio. This roadmap 
directly supports the delivery of faster and better program performance, resulting in the 
fulfillment of an agency’s core mission. The EA ties IT to business processes and results. It 
serves as a consistent, comprehensive analytical structure giving federal managers valuable 
information to make better IT investment decisions. These decisions lead to smarter, more 
efficient technology use, resulting not only in cost savings, but over time, in measurably 
improved program performance across government. 

Directly supporting the E-Govemment initiative of the PMA, the FEA Program was established 
by 0MB in February 2002 to build a comprehensive business-driven blueprint of the entire 
federal government. The FEA framework and four of its supporting reference models 
(Performance, Business, Service Component and Technical) are now used by agencies in 
developing their budgets and setting strategic goals. The fifth and final reference model (the 
Data Reference Model) is currently under OMB review and will be released soon for agency 
comment. With the completion of the five FEA reference models, the FEA will evolve into the 
“common language” for diverse agencies to use while communicating with each other and with 
state and local governments seeking to collaborate on common solutions. 

In addition to supporting agencies’ EA efforts, the federal government is using the FEA to 
identify numerous cross-agency opportunities to cut costs and increase efficiency through 
sharing common business functions and technology applications to achieve results for the 
taxpayer. In contrast to planning methods of the past, EA is a business-driven - not technology- 
driven - approach to creating “best-practice” E-Govemment solutions to bring faster, better and 
more cost-effective services to citizens. Specifically, we are enhancing the FEA to maximize the 
performance of the Federal government’s $60 billion IT portfolio by: 

• Identifying opportunities to develop common solutions within Lines of Business (LoBs), 
resulting in increased government effectiveness and taxpayer savings; 

• Linking agency program performance to strategic IT investment decisions through 
agency enterprise architectures; and 
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• Using EA-related budget requirements to ensure security and privacy considerations are 
integrated as agencies make strategic IT investment choices. 

There is significant work needed to be completed to achieve the full potential existing within the 
FEA. We are aware of the gaps existing within our emerging activities and will develop the 
remaining elements to complete the framework, for example, the Data Reference Model and 
integration of the CIO Council’s security and privacy profile into the framework. We are 
emphasizing the establishment of common language and taxonomy to represent the FEA, so 
stovepipes continue to fall. Agency alignment with the FEA needs to be transparent and 
incorporated into agency EA programs. The FEA continues to provide a transformational 
opportunity to better enable collaboration across the federal government, within and between 
agencies, and with state and local governments. 

FEA Implementation 

The FEA is being implemented in various ways. The framework has yielded results 
demonstrating a new ability for the federal government to drive collaboration and accelerate 
consolidation of redundant activities, saving taxpayer dollars. The FEA has been involved by 
providing analytical underpinning for the 24 E-Gov initiatives and the Line of Business (LoB) 
activities and is being incorporated into agency guidance and policy for use during budget 
formulation activities. In addition, we have been meeting with all agencies and have established 
a dialogue around the FEA information supplied to OMB as part of the FY05 budget process. 
OMB has been able to take advantage of FEA data for the development of the FY04 and FY05 
President’s Budgets. This year will be the first time agencies have access to and use of the same 
data to accomplish some of the objectives outlined earlier. Some specific examples of both 
federal and agency applications follow: 

Lines of Business 


“Line of Business” (LoB) is a functional representation of the overall business responsibilities of 
government. Our analysis of LoB data is a prime example of the FEA’s value in using 
architecture to identify new efficiencies in government. Rather than identifying collaboration or 
consolidation opportunities up front, and then building architectures to implement them (as was 
done with the selection of the 24 E-Gov initiatives), the LoB analysis effort is a product of 
architecture. 

Specifically, FEA review of information collected from agencies in the FY04 and FY05 budget 
processes revealed five government-wide LoB collaboration opportunities to reduce redundant 
investments and improve efficiencies. In response to this preliminary review, OMB launched a 
government-wide effort in February 2004 to analyze the first set of LoB initiatives. The LoB 
Task Forces are now using EA-based principles and proven best practices to identify business- 
driven, common solutions to transform government by breaking down traditional agency silos 
and increasing collaboration. These five LoBs and their agency task-force leads are: 

Financial Management (FM) - The Departments of Energy and Labor 
Human Resources Management (HR) - The Office of Personnel Management 
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Grants Management (GM) - The National Science Foundation and the Department of Education 
Federal Health Architecture (FHA) - The Department of Health and Human Services 
Case Management (CM) - The Department of Justice 

The LoB Task Forces will identify common solutions and collaborate with participating agencies 
to complete joint business cases by early September 2004. Implementation of these solutions 
will begin in FY05, leading to significant improvements in process efficiency, system 
interoperability, and data sharing. 

EA Assessment Framework 

Recently, 0MB developed an EA Assessment Framework to help agencies improve their EA 
programs and benefit from the results of using EA as a strategic plaiming tool. The EA 
Assessment Framework will be used annually by OMB and agencies to identify opportunities 
and facilitate the discussion of EA performance objectives. This ongoing collaboration between 
OMB and agencies will facilitate year-round architecmral improvements. These improvements 
will lead to better resource allocation decisions and enhanced efficiency and effectiveness of a 
wide range of government programs. 

OMB’s EA Assessment Framework is designed to help each agency assess the capability of its 
EA program. For our purposes, capability refers to the overall maturity of the EA’s work 
products; the ability to identify specific IT investment recommendations; the reflection of the 
FEA reference models; and the potential for intergovernmental collaboration on IT solutions. 

The OMB framework complements the General Accounting Office (GAO) EA Management 
Maturity Framework, which assesses EA program capacity. 

Results from agency EA assessment meetings have been encouraging. In general, most agencies 
have developed the methodologies and processes necessary to support their EA programs, and 
have solid descriptions of their baseline environments. In the coming months, OMB will work 
closely with agencies to integrate performance objectives and measures into their EAs and to 
develop detailed target architectures and supporting transition plans. 

In support of agency enterprise architecture efforts, OMB’s EA Assessment Framework was 
recently added as a requirement to the Scorecard of the President’s Management Agenda (PMA). 
By institutionalizing the annual review of agency enterprise architectures, improvements and 
savings can be better targeted and results measured. 

Agency Enterprise Architectures 

OMB continues helping agencies align their efforts with the FEA Program, ensuring EAs across 
government are consistent in terms of language, structure, and general approach. We are also 
working with agencies to use EA information to identify areas for interagency collaboration. 
Toward this goal, OMB started the second-phase pilot of the Federal Enterprise Architecture 
Management System (FEAMS), a web-based tool allowing agencies access to government-wide 
architecture data organized around the FEA. FEAMS is ready for agencies to use in the FY06 
budget process. For the first time ever, agencies can look across government and identify 
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potential collaboration partners and shared technology components to utilize in developing their 
own plans for IT investments. 

EA and Improved Program Performanee 

Agency enterprise-architecture data is now being used in IT. For instance, the Department of 
Homeland Security (DHS) is making substantial progress in eliminating redundant, non- 
integrated operations, systems, and processes for IT infrastructure and mission areas. DHS 
consolidated business cases submitted for the FY05 budget listed relevant systems for 
consolidation, reported plans for migration and elimination, and identified an integrated business 
process. The benefits of successfully implementing these efforts include improved capabilities 
to safeguard our nation, and taxpayer savings through the prevention of unnecessary investments. 

Another example is Federal Student Aid (FSA), which manages a $321 billion loan portfolio 
within the Department of Education. FSA used the FEA to baseline its enterprise architecture 
program, which includes business process modeling; Capital Planning and Investment Control 
(CPIC); and IT infrastructure. FSA’s EA program is enabling the consolidation of 
approximately 14 major stove-piped systems down to eight integrated systems. 

At the Department of the Interior, the Recreation.gov E-Gov initiative is using the FEA reference 
models to collaborate with the Forest Service and U.S. Army Corps of Engineers. The end result 
is better delivery of recreation-related information and services to citizens. 

EA Community of Practice 

Collaboration among agency leaders in business operations and technology, including the 
Federal Chief Information Officers (CIO) Council and its Architecture and Infrastructure 
Committee (AIC), is serving to “operationalize” EA activities and the FEA. This is beginning to 
result in tangible improvements in strategic planning and IT portfolio management. 

To support rapid improvement in agency EA practices, 0MB supported the AIC in establishing 
the Chief Architects Forum (CAF) in April 2004. The forum assists Chief Architects by sharing 
EA best practices and addressing the challenges agencies they face in developing their EAs and 
in using architecture information for key decision-making processes. The Chief Architects meet 
quarterly and maintain an ongoing dialogue on best practices and key issues. 

We are also strengthening our relationship with state and local governments through the National 
Association of State Chief Information Officers (NASCIO) and other organizations. These 
partnerships will increase the coordination and integration of intergovernmental IT resources. 

Security and Privacy 

One of our strongest areas of emphasis is on developing an FEA security and privacy profile - an 
overlay to assist federal managers in discovering early-on where risk exposure exists, the 
potential range of controls needed to address such risk, and the potential costs of those controls. 
Using the FEA privacy and security profile as a reference in the development of agency EAs is 
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fundamental to strong security and privacy. Since an EA helps to inventory agency systems and 
identify the dependencies and relationships among them, the need for security and privacy exists 
in virtually every agency program and within eveiy EA layer, including data, business process, 
and technology. These needs can have a profound impact on process and system design and 
must be fully identified, understood, and integrated at the earliest stages of planning and 
development. The FEA Program is helping agencies to achieve this type of early integration, 
promoting efficient operations and preventing unintended consequences which may require 
costly corrections at the end of development. 

Future Outlook 

Short Term 

In the short term we will focus on evolving the FEA reference models and further enhancing 
resources for agencies, such as FEAMS and the EA Assessment Framework. These efforts will 
directly result in more mature architectures and reveal increasingly useful data on federal IT 
investments. In addition, OMB seeks to develop the government-wide practice of enterprise 
architecture so agencies can proactively collaborate together to make investment decisions prior 
to submitting their agency’s budget to OMB. 

Long Term 

In the longer term, the Administration will continue to create opportunities for transforming 
government’s delivery of service to citizens. This may include identifying additional lines of 
business through FEA data and developing common solutions to be shared for improved 
efficiency and to produce results. Second, we will work to fully integrate performance 
measurement concepts throughout the FEA reference models to ensure agencies are considering 
outcomes in all aspects of IT portfolio planning. This will begin to demonstrate the return on 
investment for EA and more clearly illustrate the direct relationship of IT to program 
performance. The Administration will continue building relationships with state, local, and tribal 
governments in order for federal efficiencies to be extended vertically to help in technology 
transformation and information sharing at all levels of government. 

Conclusion 


The Administration will continue to collaborate with agencies and with Congress, state, local, 
and tribal governments to ensure the promise of enteiprise architecture is fully realized across 
government. The FEA Program and agency EA programs are starting to achieve strong results. 
Through technical development, outreach, information sharing and analysis, the FEA Program 
will continue to focus on improving program performance throughout government to deliver 
services and produce results for the citizens. I look forward to working with you on these 
matters. 



20 


Mr. Putnam. Thank you, Ms. Evans. 

Our next witness is Mr. Randolph Hite. Mr. Hite is the Director 
of Information Technology Architecture and Systems Issues at the 
U.S. General Accounting Office. During his 25 year career with 
GAO, he has directed reviews of major Federal investments in in- 
formation technology such as IRS’s tax systems modernization and 
DOD’s business systems modernization. Mr. Hite is a principal au- 
thor of several information technology management guides such as 
GAO’s Guide on System Testing, the Federal CIO Council Guide on 
Enterprise Architectures, and GAO’s Enterprise Architecture Man- 
agement Maturity Framework. He frequently testifies before Con- 
gress on such topics and is an ex-officio member of the Federal CIO 
Council. He has received a number of awards throughout his ca- 
reer, including being a 2003 Federal 100 Award winner. 

Welcome to the subcommittee. You are recognized for 5 minutes. 

Mr. Hite. Thank you, Mr. Chairman. First let me commend you 
for holding this hearing. You know, it wasn’t too long ago that en- 
terprise architecture in the Federal Government was a lot like 
what Mark Twain said about the weather: everybody talks about 
it, but nobody does anything about it. Fortunately, this has 
changed in a lot of corners of the Government, and I am cautiously 
optimistic about what the future holds in this area. 

Nevertheless, we are clearly not where we need to be when it 
comes to developing and using enterprise architectures across the 
entire Federal Government, as your statement recognized. What I 
would like to do is make two brief points, one dealing with the Fed- 
eral Enterprise Architecture [FEA], and one dealing with Federal 
agencies’ enterprise architecture maturity. 

Point one, 0MB is making progress on the FEA, but it is still a 
work in process, and what I mean by that is it is still evolving both 
in terms of content and in use. In my view, this evolution is not 
a negative, but rather a reasonable and expected phenomenon 
given the broad-based purpose and scope of such a framework. For 
example, the FEA is intended to facilitate the development of agen- 
cy enterprise architectures, no trivial feat in and of itself; promote 
the reuse of common IT components across agencies; and identify 
opportunities for interagency collaboration on common IT solutions. 
We support these goals and believe that the FEA can be an inte- 
gral part of a transparent means to accomplish this. 

Now, having said this, we nevertheless have questions about the 
FEA at this juncture, which, if addressed, we believe will increase 
the understanding about the tool and thus facilitate its extension 
and use. One question is should the FEA be represented as an en- 
terprise architecture. Our reading of it suggests it is more akin to 
a classification scheme or a taxonomy, rather than a true enter- 
prise architecture. 

A closely related question is whether the expected relationship 
between the agencies’ enterprise architectures and the FEA have 
been clearly defined. In this regard, 0MB talks about agencies 
mapping and aligning their architectures with the FEA, but what 
this really entails is not well defined, and such ambiguity leads to 
assumptions which in turn increases the risk that expectations 
don’t get met, and this is particularly true in the enterprise archi- 
tecture arena. 
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Still another question is how will security be introduced into the 
FEA. 0MB has stated that it plans to address security in the FEA 
through a security profile, but our reading of the FEA shows that 
this profile is not yet part of the FEA. And, in my view, whether 
we are talking about enterprises or we are talking about systems, 
security should permeate every element of the architecture and 
shouldn’t be an afterthought, again, whether we are talking about 
systems or enterprises. 

Point two, like the FEA, enterprise architecture programs in the 
individual agencies are still maturing. Using our framework as a 
benchmarking tool, as you alluded to, Mr. Chairman, we reported 
in September 2003 that Federal agencies’ collective progress to- 
ward effective management of architectures was limited: 22 agen- 
cies increasing their levels, 24 agencies decreasing their levels, and 
46 agencies remaining basically the same. We further reported that 
only 20 of the agencies that we looked at had established the foun- 
dation needed for effective enterprise architecture when you com- 
pare them against our most recent maturity model, which raised 
the bar on what constitutes effective architecture management. 
This governmentwide state of affairs can be attributed to several 
longstanding challenges which were the basis of some recommenda- 
tions that we made to 0MB in 2001, and then we reiterated those 
recommendations in 2003. 

In summary, development and use of architectures in the Federal 
Government are maturing, but they are not mature. Progress is 
being made, but the progress is uneven and much remains to be 
accomplished. I will say the recent steps by 0MB and the CIO 
Council to assume stronger leadership roles in this area are en- 
couraging signs; however, hard work lies ahead to clarify and 
evolve the FEA and to ensure that well-managed architecture pro- 
grams are actually established and executed, underscore executed, 
across the Government. 

As our maturity framework emphasizes, the goal is not merely 
to check the box on some form, but rather to make enterprise ar- 
chitecture an integral and useful part of informing government 
transformation and achieving breakthrough performance. That is 
the end game. 

Mr. Chairman, that concludes my testimony. I would be happy 
to answer any questions you have. 

[The prepared statement of Mr. Hite follows:] 
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Mr. Chairman and Members of the Subcommittee: 

I appreciate the opportunity to participate in the Subcommittee’s 
hearing on the status of the Federal Enterprise Architecture (FEA) 
and on the state of federal agencies’ development and use of 
enterprise architectures — two topics that are closely related. 

An enterprise architecture can be viewed as a iiidc between an 
orgaiuzation’s strategic plan and the program and supporting system 
implementation investments that it intends to pursue to 
systematically achieve its strategic goals and outcomes. As such, the 
architecture is basically a blueprint, defined largely by interrelated 
models, that describes (in both business and technology terms) an 
entity's “as is” or current environment, its “to be” or ftiture 
environment, and its investment plan for transitioning from the 
current to the future enviroiunent The use of such a blueprint is a 
reco^iized hallmark of organizations that effectively leverage 
technology in the transformation and modernization of business 
operations and supporting systems. Further, it is recognized in 
legislation and related Office of Management and Budget (0MB) 
implementing guidance. The FEA is intended to provide a 
govemmentwide framework to guide and constr^ federal agencies' 
enterprise architectures and information technology (IT) 
investments. 

My testimony today is drawn largely from our 2003 report on federal 
agencies’ development and use of enterprise architectures, which 
was based on work conducted in accordance with generally 
accepted government auditing standards.^ We augmented the results 
in this report with available irtfonnation on the recent actions of 
OMB and the federal Chief Information Officers (CIO) Coxmcil to 
address the recommendations that we made in the report This 
testimony is also based on discussions with and information from 


‘ U.S. Geiwral Accounting Office, Infounation Technology: Leadership Remains Key to 
Agencies Miking Progress on Enterprise Architecture EtTorts, GA04)4-40 fWashin^on, 
D.C.: Nw. 17, 2003). 
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OMB on the FEA, as well as discussions with GAO’s Executive 
Council on Information Management and Technology.® 


Results in Brief 

The FEA continues to evolve in both content and use, which is both 
reasonable and expected, in our view, for such a broad-based 
framework. Through the FEA, OMB is attempting to provide federal 
agencies and other decision-makers with a common frame of 
reference or taxonomy for informing agencies’ individual enterprise 
architecture efibits and their planned and ongoing investment 
activities, and to do so in a way that identifies opportunities for 
avoiding duplication of effort and launching initiatives to establish 
and implement common, reusable, and interoperable solutions 
across agency boundaries. We support this goal, and the 
development and use of the FEIA as part of the means to accomplish 
it We nevertheless observe that development and use of the FEA is 
but the first step in a multistep process needed to realize the 
promise of such interagency solutions. Because the FEA is still 
maturing both in content and in use, we have a number of questions 
that we believe OMB needs to address to maxiiniie understanding 
about the tool and thus facilitate its advancement 

1. Should the FEA be described as an enterprise architecture? 

2. Is the expected relationship between agencies’ enterprise 
architectures and the FEA clearly articulated? 

3. How will the security aspects of the FEA be addressed? 

Like the FEA, the enterprise architecture efforts of individual 
federal departments and agencies are also stiU maturing. In 
September 2003, we reported that federal agencies’ collective 


® GAO'S Exeaitive Council on Infonnatjon Management and Technology is composed of 
senior level officials from the public sector, private sector, and academia. Members include 
former CIOs for government r^encies, professors of information technology, presidents of 
private businesses, and information technology consultants. 
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progress toward effectively managing enterprise architectures was 
limited, with much work remaining.* In partictilar, the percentage of 
agencies that had established at least the foundation for effective 
enterprise architecture management was virtually unchanged j&um 
where it was in 2001 (about 50 percent). We further reported that 
when the state of enterprise architecture is conadered in gelation to 
a more recent and demanding benchmark, this percentage dropped 
to about 20 percent (in round terms), although some agencies did do 
well against this benchmark and were thus role models for other 
agencies to follow. This composite picture of immature enterprise 
architecture management can be attributed to several long-standing 
challenges, which were the basis for the recommendations that we 
made to 0MB in 200 1 and reiterated in 2003. Recently, 0MB and the 
CIO Council took steps that are consistent with many of our 
reconunendations. We support these steps, and we are Working 
coUaboratively with both organizations to maximize their 
effectiveness. However, the fact remains that until agencies have 
and use well-defined enterprise architectures, they will be severely 
challenged in their ability to effectively leverage IT in transforming 
their operations. 


Backgroimd 

The concept of using an architecture to describe an enterprise 
emerged in the mid-1980s, and over the years, the field of enterprise 
architecture has continued to evolve and mature. In the early 1990s, 
we identified an architecture as a critical success factor in allowing 
organizations to effectively apply IT to meet mission goals. Since 
then, we have worked with the Congress, 0MB, and the CIO Council 
to promote the importance of architectures and assist agencies in 
developing, maintaining, and using them. In our reviews of selected 
agency IT management practices and major systems modernization 
programs, we have consistently identified the lack of an architecture 
as a major management weakness and made recommendations to 
address this important area. 


® GAO.OWO. 
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To help overaee and budget for federal IT investments, 0MB began 
developing the FEA in 2002, and has since issued veraons of four of 
its jBve major parts. According to 0MB, the FEA is to provide a 
common, govemmentwide framework for agency enterprise 
archito:tures and FT investments. Thus far, 0MB reports that it has 
begun using the FEIA t» identify and ^dress interagency duplication 
of effort and to launch interagency projects. 


What Is an Enterprise Architecture? 

In simplest terms, an enterprise is any purposeful activity, and an 
architecture is the structui^ description of an activity. Building on 
this, we can view enterprise architectures as systematically derived 
and captured structural descriptions— in usefril models, diagrams, 
and narrative — of the mode of operation for a given enterprise, 
which can be either a ringle organization or a ftmctionai or mission 
area that trariiscends more than one organizational boundary (e.g., 
financial management, homeland security). 

The architecture can also be viewed as a blueprint that links an 
enterprise’s strategic plan to the programs and supporting systems 
that it intends to implement to accomplish the mi^on goals and 
objectives laid out in the strategic plan. As such, the architecture 
describes the enterprise’s operations in both logical terms (such as 
interrelated business processes and business rules, information 
needs and flows, and work locations and users) and technical terms 
(such as hardware, software, data, communications, and security 
attributes and performance standards). Moreover, it provides these 
perspectives both for the enterprise’s current (or “as-is”) 
environment and for its targeted fiiture (or “to-be") environment, as 
well as for the transition plan for moving from the “as-is” to the “to- 
be" environment 


Importance of Enterprise Architectures 

The importance of enterprise architectures is a basic tenet of IT 
management, and their effective use is a recognized hallmark of 
successful public and private organizations. For over a decade, we 
have promoted the use of architectures, recognizing them as a 
crucial means to a challenging goal: that is, agency operational 
structures that are optimally defined, in terms of both business and 
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technology. The alternative, as our work has shown, is perpetuation 
of the kinds of operational environments that saddle most agencies 
today, in which the lack of integration among business operations 
and the IT resources that support them leads to systems that are 
duplic^ve, not well integrated, and unnecessarily costly to 
maintain and interface. 

Manned properly, an enterprise architecture can clarify and help 
optimize the interdependencies and relationships among an 
organization’s business operations and the underlying IT 
infrastructure and applications that support these operations. 
Employed in concert with other important IT management controls 
(such as portfolio-based capital planning and investment control 
practices), architectures can greatly increase the chances that 
organizations’ operational and IT environments will be ccmfigured 
so as to optimize minion performance. Enterprise architectures are 
integral to mana^g large-scale programs in federal departments 
and agencies, as well as initiatives that span several ^encies, such 
as those currently being undertaken to support OMB’s electronic 
government (e-govemment)* and “line of Business”® efforts. 


Brief History of Enterprise Architecture Frameworks and Management Guidance 

During the mid-1980s, John Zachman, widely recognized as a leader 
in the field of enterprise architecture, identified the need to use a 
logical construction blueprint (i.e., an architecture) for defining and 
controlling the integration of systems and their components.* 
Accordingly, Zachman developed a stnicture or framework for 
defining and capturing an architecture, which provides for six 


* Acconling U> OMB, e-government is a mode of operations (using people, process, and 
technolog)r-^>aLrticulariy Welvbased Internet technology) to enhance access to and 
delivery of goverrmient information and service to citizens, business partners, employees, 
other agencies, and other levels of government. U.S. Gene:^ Accounting Office, ESectronic 
Oovemment- Initiatives Sponsored by the Office of Management and Budget Have Made 
Affxed Prtgress, GAO^-561T (WasWngton, D.C.: March 24, 2004). 

* According to OMB, the "Lines of Business" efforts will entail reviewing proposed 
investments in five areas (financial, human resources, grants, health, and case management 
systems) to identify coirunon solutions and reduce costs. 

* J.A Zachman, “A Framework for Information Systems Architecture," IBM Systems 
Journal, vd. 26, no. 3 (1987). 
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“■windows" firom which to view the enterprise.’ Zachman also 
proposed six abstractions or models associated with each of these 
perspectives.* Zachman’s framewor}? provides a way to identify and 
describe an entity’s existing and planned component parts, and the 
relationships between those parts, before the entity be^ns the 
costly and tame-consuming efforts a^ciated with developing or 
transforming itself. 

Since Zachman introduced his framework, a number of frameworks 
have emerged within the federal government, beginning with the 
public^on of the National Institute of Standards and Technology 
CNIST) framework in 1989. Since that time, other federal entities 
have issued enterprise architecture frameworks, including the 
Department of Defense (DOD) and the Department of the Treasury. 
In September 1999, the federal CIO Council published the Federal 
Enterprise Architecture Framework, which was intended to provide 
federal ^encies with a common construct for their architectures, 
thereby facilitating the coordination of common business precedes, 
technology insertion, information flows, and system investments 
among federal agencies. The Federal Enterprise Architecture 
Framework describes an approach, including models and 
definitions, for developing and documenting architecture 
descriplicms for multiorganizational functional segments of the 
federal government.* 

In February 2002, OMB established the Federal Enterprise 
Architecture Program Management Office to develop the FEA, 
which, according to OMB, is intended to facilitate govemmentwide 
improvement through cross-agency analysis and identification of 
duplicative investments, gaps, and opportunities for collaboration, 


The windows provide the viewpoints of (1) the strategic planner, (2) the system user, 

C3) the system designer, (4) the system developer, (5) the subcontractor, and (6) the system 
itself. 

® The models cover (1) how the entity operates, (2) what the entity uses to operate, 

C3) where d\e entity operates, (4) who operates die entity, (5) when entity operations 
occur, and (6) why the entity operates. 

® Similar to the Zachman framework, the Federal Elnterprise Architecture Framework’s 
proposed models describe an entity's business, data necessary to conduct the business, 
applications to manage the data, and technology to support the applications. 
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interoperability> and integration within and across agency programs. 
The filA is composed of five “reference models” describing the 
federal government’s (1) business (or mission) processes and 
functions, independent of the agencies that perform them, 

(2) perfonnance goals and outcome measures, (3) service delivery 
means, (4) information and data definitions, and (5) technology 
standards. The reference models are intended to inform agency 
efforts to develop their agency-spedfic enterprise architectures and 
enable agencies to ensure that their proposed investments are not 
duplic^ve with those of other agencies and to pursue, where 
appropriate, joint projects. The FEA reference models are 
summarized in table 1. 


Table 1 : FEA Reference Models 

Reference model 

Description 

Status 

Perfonnance reference 

Model 

Provides a common set of gerieral performance outputs and 
measures for agencies to use to achieve business goals and 
objectives. 

Version 1 .0 released 
in September 2003 

Business reference model 

Describes the hiersrdty of federal business operations 
independent of the agencies ttiat perform them, including defining 
die services provided to state £uid local governments. 

Version 2.0 released 

In June 2003 

Service component 
reference model 

Identifies and classifies IT service (i.e., application) components 
that support federal business operations and promotes the reuse 
of components across agencies. 

Version 1 .0 released 

In June ^003 

Data and information 
reference model 

Is intended to describe, at an aggregate level, the data and 
information types ^at support program and business line 
operations and the hierarchicai relationships among these types. 

Release planned in 
2004 

Technical reference model 

Describes technology that is to support the delivery of service 
components, indudng relevant standards for implementing the 
technology. 

Version 1 .1 released 
in August 2003 


Soufca; QAO MMd en OMe <iau. 


Althou^ these post-Zachman frameworks differ in their 
nomenclatures and modeling approaches, most provide for defining 
an enterprise’s operations in bo^ logical terms and technical terms, 
provide for defiiung these perspectives for the enterprise’s current 
and target environments, and call for a transition plan between the 
two. 

Several laws and regulations have established requirements and 
guidance for agencies’ management of architectures, beginning with 
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the Clmger-Col\en Act in 1996“ which directs the CICte of major 
departments and agencies to develop, maintain, and f^ilitate the 
implementation of FT architecture as a means of integrating agency 
goals and business processes with IT. OMB Circular A-130, which 
implements the Clinger-Cohen Act, requires that agencies document 
and submit their initial enterprise architectures to OMB and updates 
when significant changes to their architectures occur. The circular 
also directs the OMB Director to use various kinds of reviews to 
evaluate the adequacy and efficiency of agency compliance with the 
circular. 

OMB was 0ven explicit responsibility for overseeing government 
enteiprise architectures by the E-Gk)vemment Act of 2002," which 
established the Office of Electronic Government within the office. 
More specifically, it gives OMB the reiq)onsibility for f^rilitating the 
development of enterprise architectures within and across agencies 
and supporting improvements in government operations through the 
use of FT. 


Prior Work Indicates Opportunities for Improving Enteiprise Architectures 

We began reviewing federal agencies’ use of architectures in 1994, 
Initially focusing on those agencies that were pursuing major 
systems modemization programs that were high risk. Ihese 
included the National Weather Service systems modernization,” the 
Federal Aviation Administration air traffic control modernization,” 
and the Internal Revenue Service tax systems modemization." 


Public law 104-106, 40 U.&C. 11316. 

“Pubbc law 107-347. 

**U.S. General Accounting Office, Weather Forecasting: Systems Architecture Needed fitr 
JVatioial Weat/ier S&rvice Modemiation, GAO/AlMD-94-28 (Washington, D.C.: Mar. U, 
1994). 

‘®U.S. Gateral Accounting Office, Air T}-a3tc Control: Complete artti &iforced Architecture 
l^eeriediorFAA Systems Modernization, GACVAlMD-97-30 CWashington, D.C.: Feb. 3, 

1997). 

**U.S. Gener^ Accounting Office, Tax Systene Modernization: Blueprint Is a Good Start but 
Not YetSu&dently Complete to Build orAafiiire Systems, GAO/AIMD/GGD-98-54 
CWashington,D.C.: Feb. 24, 1998). 
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General^, we reported that these agencies’ enterprise architectures 
were incomplete, and we m^e recommendations that they develop 
and implement complete enterprise architectures to guide their 
modenazation efforts. 

Since then, we have reviewed architecture effbrte at other federal 
agencies, including the Department of Education/* the former 
Customs Service,* the fonner Immigration and Naturalization 
Service,'’the Centers for Medicare and Medicaid Services “ the 
Department of Defense (DOD),” the Federal Bureau of 
Investigation,*® and the National Aeronautics and Space 
Administration-*' These reviews have identified the absence of 
complete and enforced enterprise architectures, which has led to 
agency business operations, systems, and data that are not 
integrated and that are duplicative and incompatible. These 
condtions, in turn, have either prevented agencies from sharing 
data or forced them to do so through inefficient manual processes 
or costly, custom-developed system interfaces. 


'*U.S. General Accoiwting Office, Student Fhumdal Aid Information: Systems Architecture 
Needed to b^rove J^rtfgrams' EBSciency, GAO/AIMD-S7-122 (Washington, D.C.: July29, 
1997). 

'®U.S. General Accoxinting Office, Customs Service Modemaatim: Architecture Must Be 
CompieteafidEnf'orcedtoEffectivelyBui]dandMaintainSystems,GK(VAi'ilS>-9B‘lQ 
CWashlng(t»,D.C.: 19^. 

^^U.S. General Accounting Office, Information Technology INS Needs tx> Better Manage the 
Deveiopmentoflts Enterprise Ajvhitecture, GAO/AIMD-OO-ZIZ (Washington, D.C.: Aug. 1, 
2000 ). 

^*U.S. General Accounting Office, Medicare: Information Systems Mddemisatieai Needs 
Stranger Management and Support, GAO-01-824 (Washington, D.C.5 Sept 20, 2001). 

U.S. Getter^ Accounting Office, I}OD Business Systems Modemisation: Jmpo/tant 
Progress Made to Develop Business Enterprise Ai^tectare, but Much Work Remams, 
GAO^lOl8(Waslungton, D.C.: Sept 19, 2003). 

*“ U.S. General Accounting Office, Information Technology FBI Needs an Enterprise 
Architectareto Guide Its Modemizadon Activities, GAO-03-969 (Washington, D.C.: Sept 25, 
2003). 

“ U.S. General Accounting Office, Information Technology Ardtitecture Needed to Guide 
NASA's Financial JMsmagement Modernization, GAO-04-43 (Warrington, D.C.: Nov. 21, 
2(H)3). 
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Our Enterprise Architecture Management Maturity Framework 

To contribute to the evolution and maturity of the enterprise 
architecture discipline, in 2002, we published version 1.0 of our 
Enteipiise Architecture Management Maturity Frame work 
(EAMWF) as an extension of A Practical Guide to Federal 
Enterprise Architecture, Version 1. 0, published by tiie CIO Council. 
By arranging core elements from the practical guide into a matrix of 
five hierarchical stages and four critical success attributes, this 
framework provides a common benchmarking tool for planning and 
measuring enterprise architecture efforts.® In April 2003, we 
published version 1. 1 of this framework,® which reflects changes 
and additions that are based on comments we received on the initial 
version, as well as on our experiences in reviewing enterprise 
architecture programs. 


IheEAMMF Version 1.0 

EAMMF version 1.0 is made up of five stages of maturity, each of 
which includes an associated set of elements along with all the 
elements of tl\e previous stages. In addition to the maturity stages, 
each core element is associated with attributes that are critical to 
the successful performance of any management function. Figure 1 
shows a summaiy of version 1.0 of the framework and shows the 
key elements with the associated stages and attributes. 


“U-S. Genetal Accounting Office, Information Technology: Enterprise Architecture Use 
across the Federal Government Can Be Improved,(jkO-n2-^ (Washington, D.C.: Feb. 19, 
2002). 

General Accounting Office, Informatics Technology: A Framewoilc for Assesang and 
ImprovingEhtteJjyrise Architecture Management (Version 1.1), GAO-03-584G (Washington, 
D.C.; Apra 2003). 
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Figure 1 ; EAMMF (Version 1 .0) 
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ElAMMF Version LI 

Version l.l of this framework was released in April 2003. Like the 
initial version, Version 1.1 is based on the CIO Council guidance “ 
augmented by our experience in reviewing agency architecture 


** CIO Coundi, A Practical Guide to Federal Enterprise Architecture, Version 1. 0 (February 
2001 ). 
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programs. Changes and additioris to the framework were also based 
on comments received from federal agencies on the initial version. 
Figure2shows asummary of Versipn i.l. 
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Key Differences between EAMMF Versions 1.0 and 1.1 

Overall, version 1.1 is more demanding (i.e., sets a higher standard) 
than version 1.0 becavise version 1.1 adds content and links the 
framework to related IT management guidance, such as our IT 
investment man^^ement framework.® Key differences in version 1 . 1 
of the framework appear first in stage 2 and affect later stages either 
explicitly or implicitly. That is, some planning elements associated 
with stage 2 now propagate explicitly through later stages as plans 
are executed and architecture products are developed, completed, 
and implemented. For example: 

• Version 1.1 includes “performance" among the models that are 
needed to describe the “as-is" and “to-be" environments; these 
models are introduced into the planning elements in stage 2 and 
built upon as plans are executed: that is, as architecture products 
are developed and completed in stages 3 and 4, respectively. 

• Version l.l explicitly recognizes the need to address security in the 
descriptions of the “a^is" and “to-be" environments; this element is 
introduced in st^e 2 and reiterated in stages 3 and 4. 

• Version l.l introduces the need to plan for metrics in stage 2 and to 
measure different aspects of enterprise architecture development, 
quality, and use in st^es 3, 4, and 6. 


OMB Has Made Progress on FEA, but Questions Remain 

In 2001, the lack of a federal enterprise architecture was cited by 
OMB’s E-Govemment Task Force as a barrier to the success of the 
administration’s e-govemment initiatives." In response, OMB began 
developing the FEIA, and over the last 23 months it has released 
various versions of all but one of the five FEIA reference models. 
According to OMB, the purpose of the FEA, among other things, is 


“ U.S. General Accounting Office, Information Technology Investment Management; A 
Firamework for Assesang and Improving Process Maturity, GAOAW94G (Washin^n, 
D.C.: March 2004). 

" OMB's E^verranent Task Force identified 23 initiatives (two additional initiatives were 
subsequendy added) aimed at improving service to individuals, service to busine^es, 
intergovenunental aifrairs, and federal agency-to4gency efficiency and effectiveness. 
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to provide a common frame of reference or taxonomy for agencies’ 
individual enterprise architecture efforts and tiieir planned and 
ongoing investment activities. 

OMB reports tKat it first began using the FEA in 2002 as part of the 
fiscal year 2004 budget Qrcle to identify duplicative investments, 
gaps, and opportuniti^ for coUaboradon, interoperability, and 
integration within and across government agency programs. OMB 
has since required agencies to use the FEA in developing their fiscal 
year 2005 budget subnussior\s." Despite OMB’s progress, however, 
questions remain about the FEA 


OMB Has Cited a Number of Broad Purposes for the FEA 

OMB has identified multiple purposes for the FEA. One purpo^ 
cited is to inform s^encies’ individual enterprise architectures and 
to facilitate their development by providing a common classification 
structure and vocabulary. Another stated purpose is to provide a 
govemmentwide framework that can increase agencies’ awareness 
of IT capabilities that other agencies have or plan to acquire, so ti\at 
they can explore opportunities for reuse. Still another stated 
purpose is to help OMB decision-makers identify opportunities for 
collaboration among ^encies through the implementation of 
common, reusable, and interoperable solutions. To this end, the 
business reference model states that OMB will use the FEIA to 
analyze agency IT investments to identify 

• which agencies share common business functions, processes, and 
activities; 

• which budget requests support duplicative business functions and 
information systems; and 

• where the government is investing money on redundant capabilities. 

According to OMB, still another purpose of the FEA is to provide the 
Congress with information that it can use as it considers the 
authorization and appropriation of funding for federal programs. 


AdditiaaiGaid&nceontheFEA-relatedRequiiwaentsm OMB Circular Adi, Office of 
Managcmait and Budget, FederaJ Enterprise Architecture Program Management Office. 
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0MB Has Released Versions of Four of Five FEA Reference Models 

OMB has issued at least initial vereions of four of the five reference 
models and plans to issue the fifth m the near fiiture (see table 1). 

The following svanmarizes the purpose, content, and status of each 
reference model. 

Performance reference model According to OMB, the performance 
reference model is intended to produce FT performance information, 
articulate the contribution of IT to business outputs and outcomes, 
and identify performance improvement opportunities that cross 
organizational boundaries. 

To accomplish these purposes, the model specifies measurement 
areas (e.g., mission and business results), measurement categories 
(e.g., services for citizens), and generic measurement indicators 
(e.g., delivery time) that agencies are to use to organize their 
respective measurement indicators. It also describes a process for 
agencies to use to identify and define these measurement indicators. 
Version 1.0 of the model was released in September 2003. 

Business reference model. OMB characterizes the business 
reference model as being the foundation of the FEIA. It describes the 
businesses of the federal goverrunent, independent of the agendes 
that perform them. According to OMB, the purpose of the business 
reference model is to provide the basis for analyzing IT investments 
and assodated budget requests relative to whe^er they support 
common business ftinctions, processes, and activities. OMB expects 
agencies to use the model as part of their capital planning and 
investment control processes to help identify opportunities for 
consolidating IT investments across the federal government. 

The model consists of four business areas (1) services for dtizens, 
(2) mode of delivery, (3) support delivery of services, and 
(4) management of government resources. These four business 
areas are decomposed into 39 lines of business, which are made up 
of 153 subfunctions. Examples of lines of business under the 
“services for citizens” business area are homeland security, law 
enforcement, and economic development. For the homeland 
security line of business, an example of a subfiinction is border and 
transportation security; for law enforcement, a subfunction example 


Page 16 


GAO-04-798T 



40 


is citi 2 en protection; and for economic development, a subfunction 
example is financial sector oversight Version 1.0 of the model was 
released to agencies in July 2002. In June 2003, version 2.0 was 
released. 

Service component reference model. According to 0MB, toe service 
component reference model identifies and classifies IT sendee (i.e., 
applicatiwi) components that support federal agencies so that 0MB 
can identify, among other things, ^encies that are budding or have 
already built siindar components that can be reused. Agencies are 
expected to use the service reference model to do the same. 

The mode! is organized as a hierarchy, beginning with seven service 
domains These service domains are decomposed into 29 service 
typesisee table 2), which are further broken down into 168 
components. For example, toe customer services domain is made up 
of duee service types; customer relationship management, customer 
preferences, and customer-mitiated assistance. Components of the 
customer relationship management service type include call center 
man^ement and customer analytics; components of toe customer 
preferences service type include personalization and subscriptions; 
and components of the customer-initiated assistance service type 
include on-line help and on-line tutorials. Version 1.0 of the service 
component reference model was released in June 2003. 
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Table 2. Ser.ice Domains, the CapalHI'rties That They Describe, and Associated S«vice Types 

Service domain 

Description 

Service typ^ 

Customer servtees 

Interaction between the business arKt the 
customer, including customer*driven activities 
(directly related to ^ end custonner) 

Customer preferences, customer relationship 
managem^t, and customer-initiated 
assistance 

Process automation 
services 

Automation of processes and activities that 
support managing the business 

Tracking and workflow, and routing and 
automation 

Business management 
services 

Manageipent and execution of business 
functions and organizational activities that 
maintain (xmtinuity across the business 

Management of process, organizational 
management, supply <^ain management, and 
investment mcuiagement 

Digital asset services 

Generation, management, and distribution of 
intellectual capital and electronic media 
across the business 

Content management, knovriedge 
management, document m^agement, and 
records management 

Business anaiytbal 
services 

Extraction, aggregation, and presentation of 
information to facilitate decision analysis and 
business evaluation 

. Analysis and statistics, business intelligence, 
visualization, and reporting 

Back office services 

Management of transaction-based functions 

Data management, human resources, 
financial management, assets/materiais 
management, development and integration, 
and human capitai/workforce management 

Support services 

Cross-functiorral capabilities that are 
independent of service domains 

Security management, systems management, 
forms, cixtimunication, collaboration, and 
search 


Souicv OMB. 


sfid infotTnation reference model. The data and informatioxi 
reference model is intended to help define the types of interactions 
and information exchanges that occur between the government and 
its customers. According to OMB, the model will describe data and 
information types that support program and business line 
oper^^ons and the relationships among these types. According to 
OMB officials, the model’s release is imminent 

Technical re ference model The technical reference model is 
intended to help agencies define their respective target technical 
architectures. It describes the standards, specifications, and 
technolo^es that collectively support the secure delivery, exchange, 
and constraction of service components. OMB describes the model 
as being made up of the following four core service areas: 
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• Service access deliveiy: the collection of standards and 
specifications that support external access, exchange, and delivery 
of service components. 

• Service platform and Infrastructure: the delivery platforms and 
infrastractiire that support the construction, maintenance, and 
availability of a. service component or capability. 

• Component framework: the imderlying foundation, technologies, 
standards, and specifications by which service components are 
built, exchanged, and deployed. 

• Service interface and integration: the coDection of technolo^es, 
methodolo^es, standards, and specifications that govern how 
agencies will mterface internally and externally with a service 
component 

Each of these four core service areas is made up of service 
categories, which identify lower levels of technologies, standards, 
and specifications; service standards, which define the standards 
and technologies that support the service category; ai>d the service 
sfiecifcationr which det^s the standard specification or the 
provider of the specification. For example, within the first core 
service area (service access and delivery), an example of a service 
category is acoesscAanne/5, and service standards are Web 
browsers and wireless persona] digital assistants. Examples of 
service specificationsioT the Web browser service standard are 
Internet Explorer and Netscape Navigator, Version 1.0 of the 
technical reference model was released in January 2003 and then 
revised in August 2003 to incorporate minor revisions that were 
based, in part, on agencies’ reviews. This version — ^version i.l — was 
used during the 2005 budget process. 


0MB Has Used the FEA to Identify Five Areas for Interagency Collaboration 

As part of the fiscal year 2004 budget cycle, OMB required agencies 
to align business cases for their proposed FT investments to the 
business reference model; beginning with the fiscal year 2005 
budget cycle, agencies were required to align their business cases to 
all the available reference models (i.e., the business, performance, 
technical, and service component reference models). This alignment 
activity was intended to result in the identification of redundancies 
and opportunities for collaboration. According to OMB, the fiscal 
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year 2004 IT investment budget review proce^ identified potential 
redimdanci^ in six lines of business. F\irther analysis of these six 
lines of business as part of the fiscal year 2005 IT budget process 
resulted in 0MB settling on five lines of busine^ in which to pursue 
opportunities for collaboration (i.e., financial management, human 
resources, grants, health, and case management). 

Since then, OMB initiated a govemmentwide analysis of these five 
lines of business to examine business and IT data and best practices 
for each. According to OMB, over the next several months, agency- 
led teams will identify common solutions and define a target 
architecture that is to be reflected in a busine^ case for proposed 
rr investments for each line of business. The business cases are to 
be submitted for review in the fiscal year 2006 budget process. To 
this end, on April 15, 2004, OMB issued a formal request for 
information, seeking information fiom industry and government 
service providers on common solutions and target architectures for 
three of the five lines of business: financial management, human 
resources, and grants management 


OMB Plans to Improve the FEA and Expand Its Use 

According to OMB officials, the FEA is in the early stages of its 
development and use, with future development and uses planned. 
OMB’s plai^ for improving the FEA include releasing the previously 
mentioned data and information reference model, creating a plan for 
FEIA management and maintenance, revising and consolidating 
reference models, and expanding use of the automated tool for 
collecting FEA data from agencies. Each is discussed below. 

First, OMB plans to develop a formalized Management and 
Maintenance Plan that it says will provide explicit instnictions to 
agendes on the roles, responsibilities, standards, and expectations 
for the management and upkeep of the FEIA. Second, according to 
OMB, another planned activity is annually revising the reference 
models and consolidating all five reference models into one 
document SpecificaJfy, it plans to (1) release a new version of the 
business reference model in mid-spring of each year, so that 
agencies will be able to use it when setting strategic budget 
priorities, and (2) create a consolidated set of models that, 
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according to OMB, will facilitate integration of the reference models 
and change acix^ all the models as they are updated. Finally, it is 
expectu^ agencies to expand their use of the Federal Enterprise 
Architecture Management System, so that ^endes lliemselves, 
rather than OMB, will have the means to identify opportunities for 
collaboration internally as well as ^:ross agency boundaries. 


Agencies Have Expressed High Levels of FEA Understanding and Support 

As part of our govemmentwide report on enterprise architecture 
naaturity, we reported on federal agency views on the FEIA, 
particularly agencies’ understanding of and support for it and 
agencies’ assessment of the impact of it on their respective 
enterprise architectures In general, we reported that most 
agencies understood and supported the FEA, although a^mndful did 
not More specifically, of the 96 agencies that we contacted, about 
80 percent told us that they understood the goals and objectives of 
the FEA (about 8 percent did not). Additionally, about 67 percent 
said that they understood the approach OMB was following to 
develop the FEIA (about 13 percent did not). 

Regarding agency support for the FEA, about 80 percent ,of the 
agencies said that they supported its goals and objectives (about 6 
percent did not); about 63 percent stated that they supported OMB’s 
approach to developing the FEA (about 10 percent did not). Further, 
about 72 percent told us that their respective architectures were 
tracejdjle to the FEA (about 6 percent were not). With respect to its 
impact, about 61 percent of the agencies said that their respective 
enteiprise architectures would change as a result of the FEA (about 
8 percent did not). (See table 3.) 
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Table 3: Summary of Agencies’ Positions on the FEA 




Percentage of agencies 

Percentage of agencies 

Percentage of 
agencies that 
neither agreed nor 

Statement ' 

that agreed 

that disagreed 

disagreed 

Understand the goals and crfsjectives 

80 

8 

12 

Understand OMB’s approach to 
development 

67 

13 

20 

Support the goals and ob}ectlves 

80 

6 

14 

Support OMB’s approach to development 

63 

10 

27 

Can trace enterprise architecture to tfie 

FEA 

72 

6 

22 

Wit! change enterprise architecture as a 
result of the FEA 

61 

8 

31 

SoutekGAO. 





As the FEA Continues to Elvolve, Questions Need to Be Addressed 


Despite 0MB progress in developing the FEA, questions remain. We 
raise these questions in an effort to enhance agency understanding 
of the FEA and facilitate its use. As 0MB continues to mature the 
FEIA, these questions should be addressed. 

Should the FTIA be described as an enterprise architecture? 
discussed earlier in this statement, a true enterprise architecture is 
intended to provide a blueprint for optimizing an organization's 
business operations and implementing the IT that supports them. 
Accordingly, well-defined enterprise architectures describe, in 
meaningful models, both the enterprise's “as-is” and “to-be" 
environments, along with the plan for transitioning from the current 
to the target environment To be meaningfiil, these models should 
be inherently consistent with one another, in view of the many 
intenelationshups and interdependencies among, for example, 
business functions, the information flows among the functions, the 
security needs of this information, and the services and £q)plications 
that support these functions. 

Our reading of the four available reference models does not 
demonstrate to us that this kind of content exists in the FEA, and 
thus we believe that the FEA is more akin to a point-in-time 
framework or classification scheme for federal government 
operations. Our discussions with 0MB officials confirmed our 
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reading of the FEA- Accordingly, if agencies use the FEA as a model 
for defining the depth and detail for their own architectures, the 
agenda’ enterprise architectures may not provide sufficient 
content for driving the implementation of ^sterns. 

Is the expected relationship between agenda’ enterprise 
architectures and the FEIA clearly articulated? kccoxdjug to 0MB, 
the FEA K to iriform £^ency enterprise architectures. For example, 
OMB has stated that although it is not mandating that the biminess 
reference model serve as the foimdation for every agency’s business 
architecture, agencies should invest time mapping their respective 
business architectures to the FEA. Similarly, OMB has stated that 
agendas’ alignment of their respective architectures to the service 
component reference model and the technical reference model will 
enable each agency to categorize its fT investments according to 
common definitions. 

Such descriptions of the agency enterprise architecture/FElA 
relationship, in our view, are not dear, in part because definitions of 
such key terms as alignment, mapping, and consistencywere not 
apparent in the FEA. As with any endeavor, the more ambiguity and 
uncertainty there is with requirements and expectations,' the greater 
the use of assumptions and thtis deviation from the intended course 
of action. This is particularly true in the area of enterprise 
architecture. 

How will the security aspects of the FEA be addressed? Our work 
has found that a well-defined enterprise architecture should include 
explicit discussion of security, induding descriptions of security 
policies, procedures, rules, standards, services, and tools.” 

Moreover, security is an element of the very fabric of architecture 
artifacts and models and thus should be woven into them all. As our 
experience in reviewing agency security practices and research of 


”U.S. General Accounting Office, DOD Business ^rstems Modernization: Important 
Progress Made to Develop Business Enterprise Ardiitecture, but Much WorkBemains, 
GA003-1018 (Washington, D-C: Sept 19, 2003). 
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leading pr^tices shows, security cannot be an afterthought when it 
comes to engineering ^sterns or enterprises* 

OMB has stated that it plans to address security through what it 
terms a “security profile” to be added to the F^. However, OMB 
officials could not comment on the profile’s status or development 
plans, beyond stating that the CIO Coundl is taking the lead in 
developing the profile. 


Overall, Federal Agency Architecture Management Is Not Mature, 
but Some Agencies Are Doing Well and Efforts Are under Way to 
Advance Govemmentwide Maturity 

As we reported in 2003, while some agencies have made progress in 
improving their enterprise architecture management maturity, 
progress for the federal government as a whole has not occurred.®* 

In particular, the percentage of agencies that had established at least 
the foundation for effective enterprise architecture management 
was virtually \mchanged from where it was in 2001 (about 60 
percent). Further, we reported that when the state of enterprise 
architecture is considered in relation to a more recent and 
demanding benchmark, this percentage dropped to about 20 percent 
(in round terms), even thou^ some agencies fared favorably against 
this benchmark and were role models for others to follow. This 
composite picture of immature enterprise architecture management 
can be attributed to several long-standing challenges, which were 
the basis for the recommendations that we made to OMB in 2002 
and reiterated in 2003. Recently, OMB and the federal CIO Council 
began to take steps that are consistent with many of our 
recommendations. 


*U.S.Gaierai Accounting (^ice, lixfoimation Sccuiity Management: Learning From 
Leading Organizatjons, GAO/AIMI>-9S.86 (Washington, D.C.: May 1998). 

®‘ GACM)440. 
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Govenmientwide Progress in Managing Er\terprise Architecture Has Been Limited 

Between 2001 and 2003, little substantial change was revealed in 
agencies’ collective enterprise architecture maturity, when this is 
compared against version 1.0 of our framework.® Of the 93 agencies 
that we reported on in 2001 and 2003, 

• 22 agencies (24 percent) increased their maturity, 

• 24 agencies (26 percent) decreased their maturity, and 

• 47 agencies (51 percent) remained the same.® 

Agencies’ progress between 2001 and 2003 is similarly limited when 
we consider the total number of EAMMF core elements satisfied. 
SpecificaOy, the 93 agencies satisfied about 57 percent of all 
possible framework elements in 2001 and about ^ percerit in 2003. 
Upon further inspection, these data show that agencies improved in 
satisfying certain core elements, but these improvements' were 
offset by declines in satisfaction of other core elements. The 
following are examples of elements where agency satisfaction 
significantly improved: 

• “Metrics exist for measuring enterprise architecture benefits” (about 
a 38 percent increase), 

• “ Chief architect exists” (about a 23 percent increase), and 

• “Enterprise architecture products are under configuration 
management” (about an 18 percent increase). 

The following are examples of core elements where agency 
satisfaction significantly declined: 

• “Enterprise architecture products describe ‘as-is’ environment, ‘to- 
be’ environment, ^d sequencing plan” (about a 39 percent 
decrease), 


®®Numbers do not add to 100 percent due to rouniSng. 
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• “Enteiprise architecture products describe enterprise’s business — 
and the data, applications, and technology that support it” (about a 

36 percent decrease), 

f “Either enterprise architecture steering committee, investment 
, review board, or agency head has approved enterprise architecture” 

1 (about a25 percent decrease), and 

• “Program office responsible for enteiprise architecture development 
exists" (about a 23 percent decrease). 


For the ^ agencies that advanced one or more maturity stages from 
200 1 to 2003, completion of no single core element accounted for 
these advancements. That is, for the 22 agencies, increases in 
maturity stages are most often attributable to the fulfillment of 7 
core elements spanning 3 stages of maturity. Table 4 shows those 
newly satisfied core elements that most often accounted for an 
increase in a maturity stage. 

Table 4: Core Elements Thai Most Frequently Contributed to Maturity Stage Increases 

Agencies increasing 
maturity stage 

Core elements whose fulfillment most frequently contributed to 
increase 

Number of agencies 
fulfilling element 

12 agencies increased 

Stage 2 elements: 


maturity from stage 1 (6 
to stage 2, 6 to stage 3} 

Chief architect exists 

6 of 12 

Program office responsible lor enterprise architecture development 
exists 

6 of 12 


Committee or group representing the enterprise is responsible for 
directing, overseeing, or approving enterprise architecture 

6 Of 12 


Enterprise architecture being developed using framework and 
automated tool 

4 of 12 

8 agencies increased 

Stage 3 elements: 


maturity from stage 2 (6 
to stage 3, to stage 4, 1 
to stage 5) 

Enterprise architecture products are under configuration 
management 

7 of 6 

Written and approved policy exists for enterprise architecture 
development 

5 of 8 

2 agencies increased 

Stage 5 element: 


maturity from stage 4 

Metrics exist for measuring enterprise architecture benefits 

2 of 2 


Sourca: QAO analysis o< auivay dau. 


As with increases in agency maturity levels, no single core element 
accounted for the decreases in agency maturity between 2001 and 
2003. However, as shown in table 5, the stage 2 framework element 
requiring a program office was the most significant newly 
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unsatisfied element for the 24 agencies that had decreased maturity 
levels. 


Table 5: Core Elements That Most Frequently Contributed to Maturity Stage DecreasM 

Agencies decreasing 
maturity stage 


Number of agencies 

not fulfilling 
element 

16 agencies decreased 

Stage 2 elements: 


maturity to stage 1 (12 
from stage 2, 4 from 

Program office responsible for enterprise architecture development 

exists 

13of 16 

stage 3) 


4 of 16 

7 agencies decreased 

Stage 3 elements: 


mafijrity to stage 2 (6 
from stage 3, 1 from 

Written and approved policy exists for enterprise architecture 
development 

6of7 

stage 4) 

Enterprise architecture products are under configuration 
management 

3 of 7 

1 agency decreased 

Stage 4 elements: 


maturity to stage 3 (from 
stage 4) 

Enterprise architecture products describe ‘as-is’ environment, ’to- 
be’ environment, and sequencing plan 

1 Of 1 


Enterprise architecture products describe enterprise's business — 
and the data, applications, and technology that support it 

1 of 1 


Soutea; GAO anti/sls d stKvay dtft. 


One factor contributing to the decreases in maturity betiyeen 2001 
and 2003 is improved accuracy in agencies’ responses to our data 
collection instrument Improved accuracy is a function of 
( 1) improved agency familiarity with and understanding of 
enterprise architecture management and our framework and (2) the 
requirement in our 2003 work for documentation to support certain 
agency responses. 

Overall, the State of Architecture Development and Use in Federal Agencies Is Uneven 
and Needs to Improve 

When compared against version 1.1 of our framework, the state of 
enterprise architecture management across the federal government 
is not mature. In particular, about 21 percent of federal e^encies (20 
of 96) have the stage 2 management foundation that is needed to 
begin successfully developing, implementing, and maintaining an 
enterprise architecture, and about 79 percent of agencies (76 of 96) 
have not yet advanced to this basic stage of maturity. (One agency, 
the Executive Office of the President, was at a stage of maturity that 
can be considered effective.) This overall state of maturity is 
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consistent for each of the three agency groups surveyed: 
departments, component agencies, and independent ^encies. 

No ^gie core element that was ^ded to our framework 
contributed significantly to this current state, but the “methodology” 
subelement of the stage 2 element “Enterprise architecture is being 
developed with a framework, methodology, and automated tool” 
was the most significant factor that kept agencies from achieving 
stage 2. The absence of a “methodology" kept seven agencies from 
attaining stage 2 status. 

Nevertheless, certain core elements of version LI of our framework 
were frequently not satisfied by agencies. Of the 31 core elements in 
version 11, 17 were not satisfied by more than 50 percent of the 
agencies. Further, 8 elements associated with stages 4 and 5 were 
not satisfied by about 80 percent of the agencies. 

Although sigiujficant g^s existed across federal agencies in meeting 
the core elements of version 1. 1 of the framework, at least 80 
percent of the agencies reported performing 8 core elements that 
were related to stages 2 and 3. The most often satisfied elements 
included the following stage 2 elements: 

• “ Enterprise architecture plans call for describing both the *as-is’ and 
the ‘to-be’ environments of the enterprise, as well as a sequencing 
plan for transitioning from the ‘as-is’ to the ‘to-be’”(about 94 
percent); 

• “Enteiprise architecture plans call for describing both the ‘as-is’ and 
the ‘to-be’ environments in terms of business, performance, 
information/data, applicatlon/service, and tecl^ology” (about 90 
percent); and 

• “Enterprise architecture plans call for business, performance, 
infomution/data, application/service, and technology descriptions 
to address security” (about 86 percent). 

The most often satisfied elements also included the st^e 3 element 

• “Enterprise architecture products describe or will describe both the 
‘as-is’ and the ‘to-be’ environments of the enterprise, as well as a 
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sequencing plan for transitiorang from the ‘as-is’ to the ‘to-be’" 

(about 88 percent). 

In addition, although only one agency has achieved stage 5, many 
agencies reported satisfying the stage 5 core elements requiring that 
IT investments comply with their enterprise architecture (about 80 
percent) and that enterprise architecture is an integral component 
of their FT investment management process (about 69 percent). 

Deparlments, component agencies, and independent agencies had 
varying degrees of succ^s satisfying certain core elements within 
individual stages. In general, departments more succe^ 
satisfying lower stage elements than did components and 
independent agencies. In stage 2, for example, while 69 percent of 
departments reported using a fi-amework, methodology, hnd 
automated tool to develop their enterprise architecture, only 29 
percent of components and 50 percent of independent agencies 
reported the same. Additionally, in stage 3, while 81 percent of 
departments reported that progress against plans is measured and 
reported, only 25 percent of components and 25 percent of 
independent agencies reported the same. One possible reason for 
this situation is that OMB’s oversight of agency enterprise 
architecture efforts focuses on departments and m^or independent 
agendes-^ot on component agencies. 

Although, as a whole, departments satisfied more lower-level 
framework elements than did component agencies and independent 
agencies, departments generally still would need to satisfy' several 
lower-level framework elements to achieve a stage 3 maturity level 
On average, each department needs to satisfy 2 core elements to 
satisfy all stage 2 and 3 framework elements. 

The maturity stage of a department generalfy^ was not indicative of 
the maturity of its component agencies. For example, the 
Departments of Health and Human Services and Transportation 
reached stage 2, while their component agencies averaged stage 1. 
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Also, DOD’s Global Information Grid architecture** was at st^e 3, 
while its business enterprise architecture was at stage 1, as were its 
components, in general. Conversely, the Departments of Commerce, 
Justice, and tiie Treasury were at stage 1, with their component 
agencies averaging higher maturity levels; the compon^it agencies 
of Commerce showed a slightly higher maturity level than did 
component agencies of all other departments. That is, the average 
maturity level of all component agencies we surveyed was 1.23, but 
the Commerce component agencies averaged 1.80, largely owing to 
the maturity levels for the Bureau of the Census (st^e 3), the U.S. 
Patent and Trademark Office (stage 2), and the National Oceanic 
and Atmo^heric Administration (stage 2). The Department of 
Agriculture’s maturity level (stage 1) was the same as the average 
maturity level of its component agencies. 

Eight Agencies Were Well Positioned to Achieve Stage 5 Maturity, and Many Agencies 
Were Performing Core Elements beyond Their Assigned Maturity Stages 

Although the Executive Office of the President was the sole stage 5 
agency, seven other agencies were dose to becoming models of 
enterprise arclutecture management For example, the Office of 
. Personnel Management (OPM), which achieved st^e 1 of version 
1.1, needed to satisfy only five more elements to become a stage 5 
agency. OPM needed to satisfy one stage 2 element (“Enterprise 
architecture plans call for developing metrics for measuring 
enterprise architecture progress, quality, compliance, and return on 
investment"), one stage 3 element (“Progress against enterprise 
architecture plans is measured and reported"), two stage 4 elements 
(“Enterprise architecture products and management processes 
undergo independent verification and validation” and “Quality of 
enterprise architecture products is measured and reported"), and 
one stage 5 element (“Return on enterprise architecture investment 
is measured and reported”). 


®*The GIG architecture describes the globally interconnected, end-to-end set of information 
capabilities, associated processes, and personnel for collecting, processing, storing, 
disseminating, and managiixg information on demand to war filters, policy makers, and 
support petsonnel . 


Page 30 


GAO-04-79»r 




54 


Ninety^ix percent of agencies in stages 1 through 4 were 
perfonning at least one core element above their current maturity 
stage,” which means that as a whole, agencies are, to varying 
degrees, performing above their a^^>ed maturity stages. 

Specifically, of the 76 agencies at sts^e 1, about 95 percent were 
performing at least one core element in a hi^er maturity stage. 
About 35 percent of agencies need to satisfy only one additional 
core element to advance to at least the next maturity stage. Two of 
these agencies. Commerce and the U.S. Mint, could advance two 
stag^ by satisfying just one additional core element Commerce, 
currently a stage 1 agency, could advance to st^e 3 by satisfying the 
framework element “Program office responsible for development 
and maintenance exists.” The Mint, also currently a stage 1 agency, 
could advance to stage 3 by satisfying the framework element 
“Adequate resources exist” 


Agencies Identified Enterprise Architecttxre Management Challenges 

Agenda cor\tinue to face the same management challenges that we 
identified in 2001 — that is, obtaining top management support and 
commitment, overcoming parochialism, and having the requisite 
resources (financial and human capital) to accomplish tl>e work. 
Moreover, the prevalence of these challenges has grown. For 
example, getting top man^ement to understand the purpose, 
content, and value of architectures was seen as a challenge by about 
50 percent of agencies — ^up from 39 percent in 2001. As our 
framework recognizes, obtaining executive understanding and 
support is essential to having an effective enterprise architecture 
program. Without it, agencies will have increased difficulty in 
addressing other challenges such as overcoming parochialism 
among organizational components and obtaining requisite resources 
(funding and human c^itd). Our work in 2003 bears this out — at 
the same time that the percentage of agencies identifying top 
management understanding and support as a challenge rose, the 
percentage of agencies identifying these other challenges almost all 


“One agency — the EJxecuUve Office of the Ptesideit — is currwtly peifomung at st^e 5 
and cannot perform above its current maturiQr stage. As a result, it is excluded from Uiis 
analysis. 
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rose. For example, the percentage that identified parochialism as a 
challenge grew hrom about 39 to 47 percent. Also, while about 50 
percent of agencies continued to report funding as a significant 
challenge, the percentage of agendes that reported obtaining skilled 
staff as a challenge grew from about 32 to 49 percent (See table 6.) 


Table 6: Change In Prevalence of Enterprise Architecture Management Challenges 


Management challenge 

Percentage of agencies 
that fiequentiy identified 
management challenge 
2001 survey 2003 survey 

Fosterinq top management understandng- 

39 

50 

Overcoming parochialism 

39 

47 

Ensuring adequate funding 

50 

50 

Obtaining skilled staff 

32 

49 


Soutcc OMnlyMOl •urvayiMM. 


Agencies have also reported mixed levels of satisfaction with OMB’s 
efforts to address these management challenges. Specifically, just 
over half of the agencies were satisfied with OMB’s efforts to foster 
top management understanding and to overcome agency component 
organization parochialism (about 58 and 53 percent, respectively). 
Moreover, fewer than half of the agencies (40 percent) were 
satisfied with OMB’s actions to address their enterprise architecture 
funding and staffing challenges. (See table 7.) 


Table 7: Percentage of Agencies Satisfied with OMB's Efforts to Address Various Management Challenges 


Management challenge 

Percentage of agencies 
satisfied* 

Percentage of agencies 
dissatisfied* 

Percentage of agencies 
neither satisfied nor 
dissatisfied* 

Fostering top management 
understanding 

58 

14 

27 

Overcoming parochialism 

53 

10 

37 

Ensuring adequate funding 

40 

26 

34 

Obtaining slulted staff 

40 

15 

45 
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0MB and the Federal CIO Council Have Recently Acted to Strengthen Agency 
Enterprise Architecture Maturity 

Both 0MB and the federal CIO Councfl have long been advocates of 
enterprise architecture. For example, in collaboration with others 
and us, 0MB issued guidance on purpose and use of enterprise 
architectures shortly after passage of the CUnger-Cohen Act of 
1996." Subsequently, it incorporated enterprise architecture 
considerations into its oversight processes and ^ued guidance 
directing that agency IT investments be based on ^enc^ enterprise 
architectures.” Further, 0MB collaborated with the CIO Council and 
us on the Practical Guide to Federal Enterprise Architecture, 

Veisioti 1.0. As a means of promoting agencies’ enterprise 
architecture use, OMB has also included requirements for having 
and using enterprise architectures as part of the budget proce^, 
which began with the fiscal year 2002 budget cycle and, according to 
OMB officials, has continued since then. OMB has also worked 
through the CIO Council, which is chaired by OMB, to improve 
enterprise architecture management and use. 

Despite OMB’s longstanding advocacy and support for enterprise 
arcWtecture, we reported in 2002 that OMB needed to advance the 
level of enterprise architecture management maturity by exercising 
stronger leadership and improved oversight and by identifying 
govemmentwide solutioi^ to common enterprise architecture 
management challenges facing agencies. Accordingly, we 
recommended that the OMB Director, in collaboration with the 
federal CIO Council, use our maturity framework and the agency 
baseline information provided in our February 2002 report as the 
basis for helping agencies to advance the state of their respective 
enterprise architecture development, implementation, and 
maintenance efforts, and for measuring agency progress. We further 
recommended that in doing so, the OMB Director require eigencies 
to (1) submit to OlVIB an annuEil update of the agency’s satisfaction 
of each of the core elements contained in our maturity framework 


* OMB, Information Technology Architectures, Memorandum M-97-16 (June 18, 199T)-, 
rescinded with the update of OMB Circular A-130 (Nov. 28, 2000). 

^ OMB, Management of /federal Information Resources, Circular No. A-130 (Nov. 28, 2000). 
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and (2) have this update verified by ttie agency’s mpector general 
or comparable audit function before it is submitted to OMB. 
Additionally, we recommended that the OMB Director, in 
collaboration with the CIO Council, develop and implement a plan 
to address the govemmentwide impediments to greater agency use 
of enterprise architectures. We recommended that, at a minimum, 
this plan should include the two primary challenges identified in our 
2002 report — ^that is, agency executive management undemtanding 
of enterprise architectures and the availability of enterprise 
architecture human capital ejqjertise. Finally, we recommended that 
the director report annually to the Senate Committee on 
Governmental Affairs and the House Coimnittee on Government 
Reform on the results of OMB’s annual update of the state and 
progress of federal ^encies’, enterprise architecture efforts. OMB 
officids generally agreed with the findings and conclusions of our 
report and stated that they would consider using our framework. 

As previou^y noted, we reported in 2003 that agencies had 
collectively made little progress toward improving their enterprise 
architecture maturity. In commenting on this report, OMB officials 
told us that they were still considering using our fiamework as a 
basis for evaluating agencies’ progress in developing and 
implementing their architectures, but had not committed to doing so 
because they were still reviewing options. Additionally, these 
officials did not have any plans to address govemmentwide 
impediments to greater agency use of architectures. Further, they 
said that OMB has provided and plans to continue to provide 
information to the Congress on the slate of agency enterprise 
architecture efforts and on progress in implementing the FEA. As a 
result, we again called for stronger leadership and reiterated the 
recommendations we made in our February 2002 report, with the 
modification that OMB use version 1.1 of our framework and the 
baseline data from our 2003 report Additionally, we recommended 
that the OMB Director, in developing and implementing the plan we 
previously recommended to address govemmentwide impediments 
to greater agency use of enterprise architectures, ensure that the 
plan provides for identifying agencies that have effectively 
overcome enterprise architecture management challenges and 
sharing those and other lessons learned and best practices. Also, we 
recommended that the director, in annually reporting to the Senate 
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Committee on Governmental Affairs and the House Committee on 
Government Reform, as we previously recommended, include in the 
report what steps have been taken to implement our 
recommendations, including reasons for not adopting o\ar maturity 
framework. 

0MB and the CIO Council have recently initiated actions consistent 
with many of our recommendations. For example, the council 
established a Chief Architect Forum, the first meeting of which was 
held on April 5, 2004, and in which we participated. This forum has 
created a means for chief architects across federal agencies to 
ss^tematically collaborate on matters of mutual concern and 
interest Vehicles for this collaboration include periodic meetings, a 
listserve to sbare information and ideas, and fecial gathering that 
focus on specific issues. As another example, 0MB recently released 
for comment veraon 1.0 of an agency enterprise architecture 
assessment tool. The tool is intended to help individual agencies 
assess their enterprise architecture programs. According to 0MB, 
this initial vejcsion will be revised to refiect comments it receives. 


In summary, enterprise architecture development and use in the 
federal government are maturing, but they are not mature. Given 
that effective development and use of enterprise architectures are 
critical to federal agencies achieving breakUirough levels of 
performance, senior leadership across the government needs to 
elevate its attention to this essential transformation and 
modernization tool. While progress on this front has occurred over 
the last few years, it has been spotty, and in our view, considerable 
maturation is needed before the federal government will be 
positioned to reap the rewards that othera have reported from 
effective arclnitecture development and use. The fact remeuns that 
until agencies have and use well-defined enterprise architectures, 
they will be severely challenged in their ability to effectively 
leverj^e IT in transforming their operations. Recent steps by 0MB 
and the CIO Council to assume stronger leadership roles are 
encouTi^g. However, hard work lies ahead to clarify and evolve 
the FEIA, and to ensure that well-managed architecture programs — 
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ones that produce architecture blueprints that can be implemented 
and become integral parts of the fabric of institutional strategic 
planning, investment decision-making, and budget execution — ^are 
actually established across the government These are important 
goals, which we support, and we will continue to work with 0MB 
and the CIO Council throughout the muitistep process needed to 
ensure that the FEA is appropriately described, matured, and used, 
and to ^ance the state of agency enterprise architecture efforts. 

Mr. Chairman, that concludes my testimony. I would be pleased to 
answer any questions that you and the other Members of the 
Subcommittee may have. 


Contact and Acknowledgements 

For further information, please contact Randolph C, Hite at (202) 
512-6256 or by e-mail at hiter@gao.gov. Other key contributors to 
this testimony included Shannin Addison, Mark Bird, Barbara 
Collier, Nancy Glover, Anh Le, Nnaemeka Okonkwo, Randolph 
Tekeley, and WUliam Wadsworth. 
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Mr. Putnam. Thank you very much, sir. 

Our next witness is Mr. Daniel Matthews. Mr. Matthews was ap- 
pointed Chief Information Officer for the U.S. Department of 
Transportation in March 2003. As CIO, he serves as the principal 
advisor to the secretary on matters involving information resources 
and information services management, and provide leadership in 
using IT to achieve the Department’s goals and objectives. Prior to 
his appointment at DOT’s CIO, Mr. Matthews served as senior vice 
president of Savantage Financial Services from July 2002, where 
he was responsible for efforts to modernize the financial manage- 
ment systems of a number of Federal agencies. He spent most of 
the previous 22 years at Lockheed Martin, most recently as vice 
president. 

You are recognized for 5 minutes. Welcome to the subcommittee. 

Mr. Matthews. Mr. Chairman and members of the committee, 
thank you for the opportunity to appear today to discuss the De- 
partment of Transportation’s implementation of the Federal Enter- 
prise Architecture Program. 

The Department of Transportation Office of the CIO has oper- 
ational responsibility for departmental network and communica- 
tions infrastructure, as well as providing shared services for the Of- 
fice of the Secretary and several operating agencies currently en- 
gaged in the Department’s Information Technology services consoli- 
dation. 

It is my observation and experience at DOT that the Federal En- 
terprise Architecture initiative is working well to focus on business- 
based, results-oriented, information technology best practice invest- 
ments, their common infrastructure and external information serv- 
ices delivery. This drive is beginning to deliver results that will ex- 
pedite our ability to improve cyber security, mine data, enhance in- 
formation sharing, eliminate redundancies, and to document our IT 
costs and performance. 

Our enterprise architecture provides a clearer understanding of 
where IT dollars are being spent, what technologies support our 
business processes, who is responsible for and impacted by process 
and technology changes, and what technology standards we should 
employ today as well as in the future. 

The dot’s enterprise architecture can be described as a fed- 
erated model composed of smaller segments that are distinct areas 
of mission activity carried out from within each of the Depart- 
ment’s operating agencies, yet they are all linked to the overall 
DOT enterprise architecture. It de-emphasizes organizational struc- 
ture and shifts that emphasis to DOT missions, in particular safety 
and mobility. It promotes an end-to-end consideration of business 
process needs across the operating agencies, a focus that is at the 
heart of Clinger-Cohen Act compliance at Department of Transpor- 
tation. Implementing architectural segments is important because 
the large scope of the DOT enterprise makes it difficult to effec- 
tively fund and successfully manage a large number of enterprise 
architecture activities simultaneously. By taking a phased ap- 
proach to the development of our enterprise architecture, the De- 
partment is able to determine a prioritized sequence of activities 
that takes into account urgency, maturity of solution, and stake- 
holder support for future phases. This sequencing approach also 
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improves the likelihood of successful implementations of IT solu- 
tions and it optimizes IT spending across the Department. 

Examples of the DOT’s emphasis on enterprise architecture 
begin with my own CIO organization, where an Enterprise Archi- 
tecture Program Management Office team is dedicated to full-time 
leadership and continuity in the development, implementation, and 
maintenance of a single DOT enterprise architecture. 

A Departmental Investment Review Board, chaired by the De- 
partment’s Deputy Secretary, reviews proposed IT investments 
from across DOT and decides their appropriate disposition based on 
project assessments performed using standardized investment re- 
view criteria, including enterprise architecture alignment. 

The Department’s Architectural Review Board is the governance 
body charged with evaluating and recommending changes to the 
DOT enterprise architecture and ensuring that investments in IT 
comply with established departmental policies for enterprise archi- 
tecture, capital planning, security standards and processes. The 
dot’s Enterprise Architecture Technology Reference Model pro- 
vides the Architectural Review Board with information on specific 
technologies, hardware, and software used throughout the Depart- 
ment of Transportation enterprise. These activities reduce security 
vulnerabilities, they wean out duplicative IT spending within our 
operating agencies, and they hasten the delivery of successful IT 
solutions. When taken together, elements of this governance model 
gracefully implement the investment review requirements of the 
Clinger-Cohen Act. 

Building on our current efforts at DOT, we recently published an 
updated version of our modernization blueprint and developed sev- 
eral documents to aid in inculcating enterprise architecture under- 
standing and use. 

The Federal Enterprise Architecture implementation, while 
viewed as fairly successful thus far, does have its issues. In several 
instances the time allowed between budgetary guidance and/or 
changes and expected agency execution has been constricted. Other 
expectations, such as a full-time program manager for each initia- 
tive, is unrealistic for many small agencies with limited staff. 
These shortcomings are being reviewed and the Federal CIO Coun- 
cil is working with 0MB to ensure a workable Federal Enterprise 
Architecture process is rapidly adopted and implemented. 

This concludes my testimony. Again, I thank you for the oppor- 
tunity to discuss this important topic and, Mr. Chairman, I look 
forward to answering any questions you may have. Thank you. 

[The prepared statement of Mr. Matthews follows:] 
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INTERGOVERNMENTAL RELATIONS AND THE CENSUS 


Mr. Chairman and members of the committee, thank you for the opportunity to appear 
today to discuss the Department of Transportation’s implementation of the Federal 
Enterprise Architecture program. 

I serve as the Department’s Chief Information Officer (CIO), and I also currently serve as 
the vice-chair of the Federal CIO council. 

The DOT Office of the Chief Information Officer (OCIO) has operational responsibility 
for Departmental network and communications infrastructure, as well as providing shared 
services for the Office of the Secretary and several Operating Agencies (OAs) currently 
engaged in the Department’s Information Technology (IT) services consolidation. 

It is my observation and DOT experience that the Federal Enterprise Architecture 
initiative begun little more than two years ago is working well in driving previously 
introspective government entities with a diversity of IT initiatives and agendas to focus 
on business based, results oriented, best practices integration of information technology 
investments, their common infrastructures, and external information services delivery. 
This drive is beginning to deliver results that will expedite our ability to improve cyber 
security, mine data, enhance information sharing, eliminate redundancies, and document 
IT costs and performance. 

The Department of Transportation’s (DOT) Enterprise Architecture (EA) actively 
supports the Department’s core mission goals of Safety, Mobility, Global Connectivity, 
Environmental Stewardship, and Security by providing a framework for mapping and 
relating the elements that comprise the Department IT environment in a single location. 
The goals of the DOT Enterprise Architecture Program are to: 

> Reduce Redundancy and Overlap of Applications and Systems 

> Increase System Integration and Correlation to Business Processes 

> Improve data quality and timeliness for use in the CPIC process 

> Optimize Data Collection and Management 

> Improve Access to Information 

> Guide and Coordinate Technology Investments 

> Leverage Economies of Scale 

> Promote Current and Flexible Technologies 

> Satisfy Legal and Regulatory Requirements 
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Like most, the DOT’S Enterprise Architecture consists of a current baseline and target 
architecture; a gap analysis between the two; a project sequencing plan to close the gap; 
and a standards profile to help guide standardization. Our Enterprise Architecture 
provides a clearer understanding of where IT dollars are being spent; what technologies 
support our business processes; who is responsible for and impacted by process or 
technology changes; and what technology standards we should employ today as well as 
in the tactical and strategic future. 

At the DOT, Enterprise Architecture motivated changes are evidenced by an aggressive 
implementation and methodology responsive to OMB’s IT portfolio investment direction 
and concurrent support of our Department’s strategic plan. We see Enterprise 
Architecture as both a management program and a documentation methodology that 
together provides an actionable, coordinated view of an enterprise’s strategic direction, 
business processes, information flows, and resource utilization. 

The DOT’S Enterprise Architecture can be described as a Federated model composed of 
smaller segments that are distinct areas of mission activity carried out from within each 
of the Department’s Operating Agencies, yet linked to the overall DOT Enterprise 
Architecture. This federated view of the Department’s Enterprise Architecture represents 
a carefully considered definition of DOT’S organizational structure, business processes, 
information needs, application systems and technology. The Enterprise Architecture 
emphasizes the DOT’S focus on implementing business needs-driven IT solutions that 
contribute to and improve the Department’s mission performance and service delivery 
across all lines of business. It deemphasizes organizational structure and shifts that 
emphasis to DOT missions, in particular safety and mobility. It promotes an end-to-end 
consideration of business process needs across the operating agencies, a focus that is at 
the heart of Clinger-Cohen Act compliance at DOT. 

As captured in the graphic below. 
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implementing architectural segments is important because the large scope of the DOT 
enterprise makes it difficult to effectively fund and successfully manage a large number 
of Enterprise Architecture activities simultaneously. By taking a phased approach to the 
development of our Enterprise Architecture, the Department is able to determine a 
prioritized sequence of activities that takes into account urgency, maturity of solution, 
and stakeholder support for future phases. This sequencing approach also improves the 
likelihood of successful implementations of IT solutions and optimizes IT spending 
across the Department. 

Under a federated approach, DOT: 

> Defines the core set of rules and approach for Enterprise Architecture; 

> Applies a standard framework for the entire organization; 

> Allows for flexibility by each Operating Administration to further refine their 
vertical Enterprise Architectures; 

> Ensures that Operating Administration verticals are compliant and consistent with 
the core model; and, 

> Focuses Departmental efforts on cross-cuts and eGov initiative coordination as 
well as Operating Administration efforts on core processes. 

The graphic below highlights the continuity, or traceability from strategy to tactical, of 
our Department’s Enterprise Architecture evolution. 



Examples of the DOT’s emphasis on Enterprise Architecture begin within my own CIO 
organization, where an Enterprise Architecture Program Management Office team is 
dedicated to full time leadership and continuity in the development, implementation, and 
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maintenance of a single DOT Enteqtrise Architecture. The team supports the 
Departmental CIO Council’s Enterprise Architecture subcommittee. Operating 
Administration level working groups, and related activities. The team defines formal 
Enterprise Architecture standards, processes and practices. The team develops, manages, 
and maintains the DOT Enterprise Architecture Portal/Repository and the DOT’S IT 
Capital Planning and Investment Control (e-CPIC) environment. 

A Departmental Investment Review Board (IRB), chaired by the Department’s Deputy 
Secretary, reviews proposed IT investments from across DOT and decides their 
appropriate disposition based on project assessments performed using standardized 
investment review criteria, including enterprise architecture alignment. 

The Department’s Architectural Review Board (ARB) is the governance body charged 
with evaluating and recommending changes to the DOT Enterprise Architecture and 
ensuring that investments in IT comply with established Departmental policies for 
enterprise architecture, capital planning and security, standards, and processes. The 
DOT’S Enterprise Architecture Technology Reference Model provides the ARB with 
information on specific technologies, hardware, and software used throughout the DOT 
enterprise. These activities reduce security vulnerabilities, wean out duplicative IT 
spending within our Operating Agencies and hastens the delivery of successful IT 
solutions. While the initial stage is to identify “standards” for the Technical Reference 
Model, another effort is underway to identify products/services which are needed by 
individual organizations. These “authorized products” will be products that work in the 
COE and have been approved by the Architectural Review Board for inclusion in the 
DOT’S Enterprise Architecture Technical Reference Model. The rigor will be less than 
“standards,” but their inclusion in the Technical Reference Model is meant to further the 
need for interoperability within DOT and with our business partners. 

The DOT’S Integrated Governance Stmeture is highlighted in the diagram presented 
below. 
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When taken together, elements of this governance model gracefully implement the 
investment review requirements of the Clinger-Cohen Act at DOT. 

In support of our Enterprise Architecture, the DOT has complemented its team and 
committee activities by implementing support tools such as the DOT Enterprise 
Architecture Portal/Repository, a baseline and future Federal Enterprise Architecture 
Reference Model data repository, or Enterprise Architecture Portal, for use by DOT 
architects, capital planners and decision makers. The Portal is a custom-developed 
database with a web-interface front end, allowing for easy viewing of Enterprise 
Architecture data. The Enterprise Architecture Portal & Repository allows the Enterprise 
Architecture information to be captured for each of the sub-architecture levels and related 
both within and across the levels in a single, on-line location. DOT Enterprise 
Architecture Repository contains current and future configurations of the information and 
allows for capture of the information in a Federated view. We also leverage full 
advantage and implementation of government-wide tool sets, such as the electronic 
Capital Planning and Investment Control web-ware to document business cases and 
support OMB IT investment reporting. 

Building on our current efforts the DOT recently published an updated version of our 
Modernization Blueprint that reflects current (baseline) business and technology 
operating environment and a future (target) state that encompasses the goals of the DOT 
IT Strategic Plan, Annual Performance Plan, E-Transportation and the President’s 
Management Agenda. This Modernization Blueprint documents continued progress in 
the re-direction of the DOT Enterprise Architecture program to further incorporate the 
Federal Enterprise Architecture Framework, embrace the e-Govemraent initiatives, align 
our mission processes, and gain buy-in from the Operating Administrations. 

The DOT has developed several documents to aid in the inculcating Enterprise 
Architecture understanding and use, such as the “DOT Enterprise Architecture 
Methodology” and “DOT Enterprise Architecture Primer” respectively. 

The Federal Enterprise Architecture implementation, while viewed as fairly successful 
thus far, does have its issues. In several instances the time allowed between budgetary 
guidance and/or changes and expected Agency execution has been constricted. Other 
expectations, such as a full time program manager for each initiative is unrealistic for 
many small agencies with limited staff. These short-comings are being reviewed and the 
Federal CIO Council is working with OMB to ensure a workable federal Enterprise 
Architecture process is rapidly adopted and implemented. 

In summary, let me again state the Department of Transportation’s support for and use of 
the Federal Enterprise Architecture instrument in identifying, relating and managing IT 
portfolio investments, OMB proactive sponsorship of the FEA initiative. I thank the 
committee for the opportunity to speak with you regarding this matter and answer any 
questions that you may have. 
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Mr. Putnam. Thank you very much. 

Our next witness is Kim Nelson. In November 2001, Ms. Nelson 
was sworn in as Assistant Administrator for Environmental Infor- 
mation and CIO of the Environmental Protection Agency. Prior to 
joining EPA, Ms. Nelson served the Commonwealth of Pennsyl- 
vania for 22 years. During her career, she worked in the Senate of 
Pennsylvania, the Public Utility Commission, and the Departments 
of Aging and Environmental Protection. For the past 14 years Ms. 
Nelson held a number of positions in the Pennsylvania Department 
of Environmental Protection. She was the first Director of the Pro- 
gram Integration and Effectiveness Office, the first executive to 
hold the position of CIO, and most recently served as Executive 
Deputy Secretary. She was primarily responsible for managing de- 
partment-wide projects with a goal toward improving processes and 
integrating programs and functions. She was recognized for out- 
standing service on three occasions during her career with the De- 
partment of Environmental Protection. 

Welcome to the subcommittee. You are recognized. 

Ms. Nelson. Thank you. Chairman Putnam, for the opportunity 
today to testify about the progress being made by 0MB and Fed- 
eral agencies to develop and implement the Federal Enterprise Ar- 
chitecture, and some of the challenges that the agencies are facing 
in aligning their own architectures with that of the Federal enter- 
prise. 

Today my testimony is going to reflect my dual role, as you men- 
tioned, as CIO at the Environmental Protection Agency, but also as 
Co-Chair of the Federal CIO Council’s Architecture and Infrastruc- 
ture Committee. 

We live in a point and click culture that has incredibly high ex- 
pectations for government. In the past, when governments wanted 
to improve service delivery, the typical response was to move some 
boxes on an organization chart and the reassignment of people. But 
today it is possible to improve our government services through the 
alignment of our information systems by looking at our common 
business functions from across different organizations. 

The FEA provides that ability, the ability to look across the Fed- 
eral departments, the agencies, to look at their missions, to look at 
their strategic goals, their programs, their data, and their informa- 
tion technology, and using it as a planning tool which allows the 
Federal Government to take advantage of the IT revolution and en- 
sure the responsible spending of over $60 billion of the Federal IT 
budget. It is the one blueprint that will lead to a more efficient de- 
livery of services and is key to the citizen-centric government that 
we all seek. 

In the last year I would say I have seen what I consider to be 
very significant progress in the implementation of the FEA. 0MB 
has completed work on all major components of the FEA reference 
model and they are giving the Federal agencies a common way to 
look at their business functions and align our investments appro- 
priately. EPA, like a lot of other Federal agencies, is now mapping 
our own architecture and our own blueprint to those in IT invest- 
ments under the Federal model. 

A couple of other examples of some progress are the CIO Coun- 
cil’s development of a reusable component strategy. That strategy 
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will enable an IT service built by one agency to be used by others, 
and the development of a draft security and privacy profile. 

The 24 e-Gov initiatives and the five Lines of Business are prov- 
ing to be what I consider to be real-life laboratories that highlight 
for 0MB and the Federal CIOs the critical Federal Architectural 
design decisions needed to achieve both information integration 
and information sharing throughout all levels of government. 

As for some of the challenges, I think your charts up there speak 
well to some of those we are facing. The General Accounting Office 
recently reported that most of the Federal agencies are still in the 
development stages of building their architectures. To quickly in- 
crease that capacity, 0MB and the CIO Council have created a 
Chief Architects Forum, where all the chief architects can leverage 
their efforts in addressing the specific strategic management and 
operational challenges that were noted in that report. 

Frankly, I think our challenge with enterprise architecture is 
that it is still a relatively new discipline to a lot of people, and like 
all new disciplines, it is going to require an acculturation process. 
Each Federal agency has to integrate enterprise architecture into 
the fabric of its strategic management culture before that agency 
can begin to eliminate redundancies, target citizen services, and in- 
tegrate the information for improved decisionmaking. It is not an 
IT tool, it has to become part of the strategic management process 
of the organization; and that is not an easy process to change. 

Finally, I would like to address the issue of interoperability as 
it relates to the Federal Enterprise Architecture and networks that 
are currently being built by governments. 

Within EPA, we are using the enterprise architecture to design 
and implement services for environmental decisionmakers across 
the country. Approximately 95 percent of all of the information in 
EPA’s major systems come from State and tribal governments. 
With that being the case, and also understanding that all of our 
major air, water, and waste laws are heavily delegated to the 
States, we have to work with those partners on the exchange of in- 
formation. This practical business reality drives the approach we 
are taking to enterprise architecture. We have to have a collabo- 
rative effort with our States and tribes to implement common data 
standards; we have to implement something that we have called 
our Central Data Exchange for reporting purposes; and we are de- 
signing and implementing our environmental exchange network. 

This network, which is becoming a reality as we speak, we have 
10 States with operational nodes on the network, is due in large 
part to the $25 million State and tribal grant program begun by 
President Bush and funded by Congress the last 3 years. Our 
strong partnership with our State co-regulators will continue to 
drive our innovation at EPA and is going to require EPA to work 
not just vertically with environmental agencies, but horizontally. 
We have to work across the Federal Government, particularly with 
health and resource agencies, to better demonstrate results in pro- 
tecting human health and safeguarding the natural environment. 

So I thank you for the opportunity to appear here today, both 
representing EPA as well as the Federal CIO Council’s Architec- 
ture Committee. 

[The prepared statement of Ms. Nelson follows:] 
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Good afternoon. Thank you for the opportunity to testify about the progress being 
made by the Office of Management and Budget (0MB) and federal agencies to develop 
and implement a Federal Enterprise Architecture (FEA) and the challenges of aligning an 
individual agency’s Enterprise Architecture with the FEA. This testimony reflects my 
roles as the Chief Information Officer (CIO) at the U.S. Environmental Protection 
Agency (EPA) and as Co-chair of the Federal CIO Council’s Architecture and 
Infrastructure Committee. I appreciate having this opportunity to appear before this 
subcommittee today to discuss this important issue. 


With the rapid advances in information technology, the expectation that the 
government’s vast supply of information and myriad services be delivered on demand is 
ever-increasing. We live in a point-and-click culture and the expectation that government 
should and can adapt is understood by the Federal CIO Council. In the past, when 
government wished to improve its services, the typical response was to reorganize the 
boxes on an organization chart and move the people. Today, it is possible to improve 
government services through carefully aligning the information systems of common 
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business functions from different organizations. We saw this happen with the recent 
rollout of various E-govemment initiatives. 

The FEA creates the ability to look across federal departments and agencies at 
their missions and strategic goals, programs, and their supporting data and information 
technology (IT). This is the planning tool that allows the federal government to take 
advantage of the IT revolution while ensuring the responsible spending of the federal IT 
budget. It is the one blueprint which will lead to a more efficient delivery of services and 
is the key to citizen-centric government. 

I have seen significant FEA progress during the past year, OMB has completed 
work on all major aspects of the FEA reference model, giving federal agencies a common 
way to look at their business functions and align their information investments 
appropriately. Without this common reference model, each individual federal department 
was creating “silo” Enterprise Architectures (EA). EPA, like other federal agencies, is 
now mapping its own in-house EA blueprint and IT investments to the federal model. 

Other specific instances of progress are the CIO Council’s development of a 
reusable components strategy — enabling an IT service built by one agency to be used by 
others. Progress on the privacy and security architecture has been made with the 
guidance and tools being developed by federal agencies to ensure that their information is 
protected and shared appropriately. 


- 2 - 
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Finally, the 24 E-govemment initiatives and the five Lines of Business are 
proving to be the real-life laboratories which highlight for 0MB and the federal CIOs the 
critical Federal Architectural design decisions needed to achieve both information 
integration and information sharing throughout all levels of government. 

As for challenges, the General Accounting Office (GAO) recently reported that 
most federal agencies are still in the development stages of building their in-house EA 
capability. To increase that capacity quickly, 0MB and the CIO Council have created a 
Chief Architects Forum, where all chief architects can leverage their efforts in addressing 
the specific strategic, management and operational EA challenges. From this grass roots 
group, we have heard chief architects say that their greatest challenge is educating their 
own senior officials that EA is not just an IT concept but a strategic management 
planning tool that positions Agency leaderships to manage the complexities of programs 
and the delivery of their services. 

I think the major challenge is that EA is a new discipline and like all new 
concepts it will take time for it to take hold. This new discipline is designed to take 
advantage of IT technology to deliver results and customer satisfaction in a world of 
complex business relationships. Federal executives must understand that the federal 
government is exactly that — a very complex set of business relationships. It is important 
that each Federal agency integrate EA into the fabric of their respective strategic 
management culture so they can begin to eliminate redundancies, target citizen services, 
and integrate information for improved decision making. 


- 3 - 
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Finally, I would like to address the topic of “interoperability” as it relates to the 
FEA and IT networks being built with other levels of governments and the private sector. 
This is a key challenge facing many federal agencies today. 

First, in order for the federal government and our partners to truly achieve 
interoperable networks, appropriate standards must be developed and agreed to, including 
data standards. The FEA model provides the foundation for standardizing data in its data 
reference layer — defining “what” data the federal government needs to do its business. 
One important criterion for achieving successful interoperability of networks is 
agreement by all parties on data standards. 

Now that significant progress has been made in getting our owm federal house in 
order via the FEA, we must begin reaching out to our IT counterparts at the state, tribal, 
regional, county and local levels to design the intergovernmental data sharing 
architecture — setting forth the minimum technical standards and services needed to build 
networks that can communicate when necessary. It is important to learn from the efforts 
of the Departments of Homeland Security, Health and Human Services, and Justice, and 
EPA, to name just a few, which are actively partnering with state, local, and tribal 
organizations and industry on the development of standards to significantly improve 
interoperability. Additionally, these Departments are working toward the implementation 
of a blueprint to promote citizen-centric government and more rapid delivery of services. 


- 4 - 
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Within EPA we are using the EA to design and implement services for 
environmental decision makers across the country. Approximately 95 percent of the 
information in EPA legacy systems comes from state and tribal partners. Under the 
major federal air, water, and waste statutes, a majority of operational responsibilities are 
delegated directly to these partners. This business reality drives our approach to 
enterprise architecture: a strong collaborative effort with states and tribes to design and 
implement common data standards; the implementation of a Central Data Exchange 
(CDX) — our single point for receiving and sharing reports and data regardless of the 
source (e.g. states, tribes, and regulatory facility) or type (e.g. Toxic Release Inventory, 
water discharges, and drinking water lab results); a heavy reliance on the integration of 
air, water, and waste information to support a holistic look at regulated facilities; and a 
sharing of information to gain a better understanding of the effects of activities on human 
health and ecosystems. 

In closing, with leadership from the President and support from the Congress, 
EPA is building an Environmental Information Exchange Network due in large part to a 
state and tribal program begun by President Bush and funded by Congress. Our strong 
partnership with state co-regulators will continue to drive innovation and will require 
EPA to work across agency lines within the federal government particularly with health 
and resource agencies, to better demonstrate results in protecting human health and 
safeguarding the natural environment. 


- 5 - 
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Mr. Putnam. Thank you all for your opening comments. 

Ms. Evans, GAO reports in its testimony that 0MB was unable 
to comment on the status and development of the security profile 
the FEA component is intended to address IT security. What is the 
status of the security profile and what are the development plans? 

Ms. Evans. Currently, we are working with the AIC off of the 
CIO Council to develop those profiles, and we have a plan, and Kim 
can probably speak more specifically to the due dates where these 
plans in the profiles will come forward to the Council and then 
come forward to 0MB, so I would yield to her on the specific dates 
of those profiles. 

But I would like to comment on one thing, and there was a lot 
of discussion going forward, and as the vice chair of the CIO Coun- 
cil when these efforts were going on, while we were talking to 
0MB, we specifically asked not to have a specific security reference 
model. And the reason why we asked not to have that was because 
we didn’t want to have security segregated from all the models. 
What we wanted to ensure was that we had worked so hard and 
came so far in ensuring that cyber security and overall risk is 
being looked at as each investment goes forward and how you man- 
age your program overall, that we had concerns as a council that 
if we had a separate model, that we may start down the path again 
of separating it without always thinking about it going forward. So 
that is why we are taking the approach of having it be overlaid 
across the framework and it will go through all the models that 
way. 

Mr. Putnam. Ms. Nelson. 

Ms. Nelson. The committee that is working on that security and 
privacy profile is actually meeting as we speak to review some of 
the most recent comments that have been received. We hope that 
document will be available before the end of the summer, and once 
that is out and is in use, we will start working on another revision. 

The one thing I want to point out about that profile, what is so 
important about it, it really does provide the opportunity for agen- 
cies to start thinking about security on day 1 and privacy on day 
1 versus thinking about security and privacy when you are ready 
to roll out a system or once you are into the later design stages. 

Mr. Putnam. Mr. Hite, do you wish to add anything or respond 
to the response? 

Mr. Hite. I offer a couple thoughts. I agree that security is part 
and parcel of each of those reference models, it is not a standalone 
item, and it needs to be interwoven explicitly into those models. 

I think there are lessons learned out there. I know IRS went 
through the same process where they found it useful, after trying 
to deal with the security elements of their enterprise architecture, 
to explicitly extract security as a separate visible view into the ar- 
chitecture so that they would in fact be able to make informed deci- 
sions about how complete and correct they were in defining their 
security profile. 

So I think there are lessons learned out there in terms of how 
to proceed in introducing security into the architecture. But I 
would reiterate what I said in my oral statement, that it is not 
something that is done after the fact and you try to lay on top of 
it. Rather it is something that is done in concert with defining the 
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business and the data and the technical, etc. elements of the archi- 
tecture. 

Mr. Putnam. The relationship between the development of the 
FEA and the agency EA efforts presents something of a chicken 
and egg dilemma. The FEA is designed to provide a framework to 
facilitate the adoption of standards into common Lines of Business. 
Agencies were required to develop their own EAs prior to work on 
the FEA began to identify potential opportunities for standardiza- 
tion. How is 0MB mediating these competing influences? 

Ms. Evans. Well, actually, I have the opportunity to talk from 
both sides of the fence on this particular issue. Coming from an 
agency where the work had already started, because having an en- 
terprise architecture is not a new requirement that the agencies 
were to have; they were to have modernization blueprints. We were 
supposed to have all of these things going forward. But as we con- 
tinue to evolve, and I think that it has been clear and it has been 
said by all the distinguished members of the panel today, that this 
continues to evolve, and it is not like you finish the work and you 
are done and you move on. These things have to continue to evolve 
and the work has to continue to progress, and it is important that 
0MB now, in this new role that I am in, continues to provide the 
leadership through the framework and through this effort so that 
we can then ensure that the agencies’ investments and the deci- 
sions that they are making support the outcomes that they intend 
for the overall programs of their departments. It isn’t so much the 
IT itself, but how is the IT supporting the overall program out- 
comes? 

So we are working, and we continuously work, to improve the 
models and realign those, but also to continuously provide feedback 
to the agencies so that their ongoing efforts can align with what 
we are doing governmentwide as well. 

Mr. Putnam. The initial development of an EA is a huge invest- 
ment in time, dollars, talent. Recognizing that the maintenance of 
an EA is an ongoing process, when might we expect to see some 
dividends returned on this investment? 

Ms. Evans. Well, I would argue that you are seeing them happen 
right now live, and the reason that I would argue that is that 
through the efforts and with the budget submissions that came in 
through 2004 and 2005, 0MB had the opportunity to really analyze 
across the Government where they could see redundant invest- 
ments or where it looked like agencies were going in a similar di- 
rection. That is now what we are calling the Lines of Business 
analysis. And so we have those Lines of Business going forward. 
We know how much the agencies intended to invest in that area, 
we know the numbers of investments that are in those areas, and 
so now what we are doing is going forward and saying this is an 
opportunity; “you guys are all worlang in this same area here,” “let 
us come up with a common solution so that we can reduce the cost, 
make use from lessons learned, and be able to go forward with a 
common solution.” So you are seeing it now. 

Do I have quantifiable benefits? The answer would be no because 
we haven’t defined the common solution. We are targeted to do 
that in this upcoming month. We had sent out a request for infor- 
mation, and I am happy to say we got the submissions in and we 
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have well over 100 submissions that came in responding to the 
Lines of Business in our questions on that and what is the best 
way for the Government to proceed. That analysis is going on now, 
and when we come to what the common solution will be, we will 
have projected benefits that we believe we will be able to obtain. 

Mr. Putnam. Do you know how much we have spent on FEA ef- 
forts so far? 

Ms. Evans. It is outlined on the Exhibit 53s, but we actually 
have it. It is mixed in with the overall planning. I can get you that 
number and get back to you and give the number for fiscal year 
2004 and 2005, if you would like, sir. 

Mr. Putnam. Please. And while we are talking about 2004 and 
2005, you raised this in your last response about some of the dupli- 
cation of effort that was identified, how many duplicate invest- 
ments were identified? 

Ms. Evans. OK, I have that for you. I do have that. OK, in fiscal 
year 2004 and 2005, we have the dollar amounts, but the top Lines 
of Business based on what we have done so far is there is a cat- 
egory called Information Technology Management, which includes 
our cross-agency investments. So the account that we have of in- 
vestments there are 822 investments. Financial Management, 
which is one of the Lines of Business that we are currently looking 
at right now, we have 445 investments in that area. The Knowl- 
edge, Creation and Management, which is another top Line of 
Business that we have identified through investments overall, 
there are 251. 

So we look at these and we say, OK, there is a lot of potential. 
When you start looking specifically at the ones that we have out- 
lined, and looking forward and saying, OK, for Human Resources 
how many do we have in there, for investments we have 89 Human 
Resources investments that showed up in the 2005 budget. For 
Grants Management we have 36. So when we start looking at that 
and then we look at the new development dollars that are associ- 
ated with each of those, for example, in Human Resources, with the 
89 investments planned, there is planned new development dollars 
of $215 million associated with that, which means that there is a 
possibility that we should be doing things in a consolidated way 
that could reduce that implementation cost. 

From a general appearance, from the 50,000 foot view, when you 
come into 0MB, from our perspective it looks like it is all duplica- 
tive, because when you start really looking at what is the business 
that an agency does, the core accounting types of functions, all 
agencies do core accounting; they have general ledgers, they 
produce financial statements. So from our perspective, from an 
0MB perspective, it all looks duplicative. However, when you have 
to start getting down into how does an agency manage from day 
to day, what are they doing, you have to then step back and really 
use this as the tool that it was intended: it is to start that discus- 
sion, it is to start delving down and doing the analysis. Is this one 
investment that was counted six times in a business case going 
across or is it truly six different investments within an agency? 
And that is one of the things that we have learned through the 
business cases and getting the information in from the business 
cases, is that we need to continuously give better guidance to the 
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agencies so that we can then say, OK, this really is truly duplica- 
tive or, no, this is the one investment that was counted six times 
coming across and it is really a corporate, departmental knowledge 
management system that each agency is counting as they do their 
business case. 

So that is why we go out and we meet with the agencies. We 
have done the analysis, this high-level analysis, and we hand it 
back to the agency, and that is the assessment framework that we 
are doing. And we say from our viewpoint this is what it looks like. 
We are asking you now, through your budget cycle, through your 
spraying and your planning cycles and your capital investment 
plans, to look at these investments. Is it just a data issue or do you 
truly have that many duplicative systems? And if you do, this is 
your opportunity to do something about it. 

Mr. Putnam. How about gaps? Do you have a number on the 
gaps that were identified? In the 2004 and 2005 budget submis- 
sions, when you reviewed those, were there things that stood out 
as being common gaps that needed to be filled? 

Ms. Evans. We looked more, when we were doing the analysis, 
to what it appeared that agencies were investing in, not so much 
was there a big gap overall. I mean, we do know, for example, that 
EVMS project management types systems, we don’t have those, so 
that was one and that was written into the scorecard so that could 
then ensure the investments going forward. But what we really are 
trying to do is get a handle on is this really a duplicative invest- 
ment. And the other piece is if you have this service component, 
if you have this type of service that you are doing in your agency, 
can you leverage that now across with other partners, versus some- 
one who says, oh, I am starting up a new system, and we have an- 
other one that looks very mature over here. 

So we have tried to ensure that collaboration is occurring among 
the agencies, so we haven’t really looked at what gaps analysis, 
other than in our skills gaps, which GAO has brought up about 
chief architects and our overall human capital skill gaps of project 
management that we need. 

Mr. Putnam. Let’s talk about the skill gap a little bit. A number 
of agencies, as Mr. Hite pointed out, reported there was a scarcity 
of skilled architecture staff. Have there been problems recruiting 
and retaining the skilled personnel to develop and implement EAs? 

We will start with Mr. Matthews. 

Mr. Matthews. At the Department of Transportation we have 
been blessed that we have two core architects; one is a gentleman 
serving on my staff, another comes to us from the FAA. And they 
have been spearheading inside the department the enterprise ar- 
chitecture requirements. They have been working with all of the 
operating agencies to bring them up to speed on the enterprise ar- 
chitecture process and also giving them some preliminary or primer 
type information on enterprise architecture and what it means to 
them on a day-to-day basis. But, by and large, in the market place 
there are few resources available to draw on for enterprise archi- 
tecture. Additionally, as we bring resources into the Federal Gov- 
ernment, their ongoing work over time has to be considered and 
how to keep their skills updated and upgraded with the current go- 
ings on in the marketplace. 
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Thank you. 

Mr. Putnam. Ms. Nelson. 

Ms. Nelson. I concur. 

Mr. Putnam. What do you see as being the utility of an FEA as 
you set about developing your own agency’s EA? 

Ms. Nelson. In EPA, we were one of the agencies that were 
working on our architecture before the EE A was in place, so what 
I see as the benefit of the EEA at this point in time is using it, 
as well as the new Eederal Enterprise Architecture Management 
System that will be put in place, it provides an opportunity for the 
agency to get an early view of what work is being done in other 
Eederal agencies. So where we might have opportunities for col- 
laboration, both in terms of some of the products that we have de- 
veloped that we might be able to roll out to other agencies to use, 
reusable components, like our Central Data Exchange, as well as 
looking at work that other agencies have done that might allow us 
to avoid our own significant investments. 

So using that new management system which will be available 
to agencies for the first time, you will be able to look across the 
Eederal Government in an easy-to-use tool and see what kind of in- 
vestments and projects are underway, and hopefully avoid earlier 
in the process, redundancies or duplication. 0MB has been able to 
do that after submissions have been made. Like everything else, 
you want to get ahead of the curve and you want to be able to 
make those decisions earlier in the process rather than later. 

Mr. Putnam. Earlier in your testimony, Ms. Nelson, you referred 
to the Chief Architects Eorum. They met for the first time in April 
of this year to identify the individuals responsible for their own 
agencies’ EA efforts and discuss common concerns. The forum was 
convened by the CIO Council. What role is the Chief Architects 
Eorum playing in the development of the EEA and what is the rela- 
tionship between the forum and the CIO Council? 

Ms. Nelson. Some chief architects from throughout the Eederal 
Government have been actively engaged in all aspects of the Eed- 
eral Enterprise Architecture, and they have done that through the 
CIO Council’s Architecture and Infrastructure Committee, of which 
I am the co-chair, only since December. When the most recent, I 
guess the third, GAO report came out, my colleague and my co- 
chair, John Gilligan, who is the CIO for Air Eorce, decided we 
needed to take a step back. As the co-chairs of the Architecture In- 
frastructure Committee, we realized that the work plans we had 
for that committee for the next year may have been too aggressive 
if in fact most agencies, as GAO indicated, were still at stage 1. 
And one of the things we did was to say we really need a large 
forum, an opportunity for the chief architects to talk to one an- 
other. 

Before that forum was held in April, the chief architects from the 
agencies had never once been brought together. So with the forum 
and quarterly meetings now, they have an opportunity to discuss 
common issues, challenges, hurdles, solutions, best practices, and 
hopefully we can use that as an opportunity to work with GAO and 
say what are the most common — and Mr. Hite was at that intro- 
ductory meeting — what are the most common challenges and how 
can we quickly move forward on some easy solutions with the goal 
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Mr. Gilligan and I have is using that forum to quickly get as many 
agencies as possible to stage 2 and stage 3, because while that col- 
umn is very big under stage 1, we think there are some simple so- 
lutions where we can quickly slide that column over to stage 2, and 
we want to use the forum to do that. 

Mr. Putnam. Do you want to elaborate on what some of those 
easy things would be to get everybody into stage 2? 

Ms. Nelson. Sure. Well, I’ll speak for my own agency. My own 
agency went from a three in the first GAO evaluation to a two to 
a one. That is not good progress. 

Mr. Putnam. Going the wrong way. 

Ms. Nelson. It is a slide, a slide the wrong way, you are right. 

We feel that right now, with some simple changes we have made, 
we are probably at a three, and using the 0MB self-assessment, 
probably have rated ourselves as a three. Simple thing. We have 
never had a formal written policy. 

Mr. Putnam. Wait a second. You gave yourself a three, but they 
gave you a one? 

Ms. Nelson. Well, they did, but the one thing you have to under- 
stand about the GAO policy or the GAO approach, and I think it 
is a good approach, but the one thing you have to understand about 
it is you could get 31 out of 32 right, and in most classrooms across 
the country that is an A, that is close to a 95 percent 

Mr. Putnam. Even under No Child Left Behind. 

Ms. Nelson. But under the GAO framework, if you got 31 out 
of 32 correct and the one you didn’t get correct is a stage 1, then 
you are way back at the beginning. 

Mr. Putnam. Do you hear that Mr. Hite? She doesn’t like your 
grading scale. 

Ms. Nelson. So you do have to delve down a little. And I am not 
arguing. I think the questions they are asking are the right ques- 
tions, but you have to understand that. 

So, for instance, all through stage 1, 2, and 3 there are two 
things we can take care of. One of them is do we have enough re- 
sources. We answered no because at that period of time we were 
in a freeze. We do have enough resources now. That is easy. Check- 
mark. That automatically takes us to stage 2. Stage 3, we did not 
have a formal written policy that the Administrator had signed. 
Even though we are using the architecture, it is part of our invest- 
ment process, we are applying it, we have aligned it with the FEA. 
Because there wasn’t a piece of paper with Administrator Mike 
Levitt’s signature on it, it kicked us all the way back. We will have 
that policy signed in the next few weeks; we are working it through 
the process now. 

There are things like that many agencies have cited, and we are 
helping them find the best policies throughout the Federal Govern- 
ment and get them in place. But what is important is you have to 
use them. Just having that piece of paper signed is meaningless if 
you are not really using it. 

Mr. Putnam. Mr. Hite. 

Mr. Hite. I would offer a couple additional thoughts to amplify 
on what Ms. Nelson is saying. 

What you see on that chart is a point in time representation. 
Most of those responses were as of about 10 months ago. So the 
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way things are today I would hope are much better than they were 
then. And as Ms. Nelson is saying, they are in her situation much 
better. 

The other thing to keep in mind when you look at that is that 
is a representation at an aggregated level of a lot of detailed infor- 
mation. When you aggregate information, you can lose specifics, so 
you have to have rules governing how you aggregate it. The rule 
that we used in applying our framework was in order to be at a 
stage, you need to satisfy all core elements at that stage. If you 
don’t satisfy all, you don’t qualify for that stage. So embedded in 
that is the reality that an organization could be not satisfying one 
stage 2, and thus be at stage 1, and they may be satisfying a half 
a dozen stage 3, 4, and 5 elements. That level of detail is not in 
an aggregated view, it is in the details of what we reported. 

And, of course, the other thing to keep in mind, the reason we 
adopted that philosophy is these things, these core elements that 
needed to be present were not trivial things; they all have a very 
real purpose, a purpose that is grounded in best practices, a pur- 
pose that is extracted from the Federal CIO Council practical guide 
on managing enterprise architecture. So they are not things that 
we came up with, saying this would be nice to have; these are fun- 
damentals. 

Mr. Putnam. What about this signature thing? If they have this 
great policy and they are doing it, and they just have a slow bu- 
reaucracy that the Administrator can’t get around to rubber-stamp- 
ing this policy that is already in place, that is really enough to 
backslide two grades? 

Mr. Hite. Well, the core element that needed to be met relative 
to stage 2 was that you had a policy governing enterprise architec- 
ture development, and whether in EPA’s case it was because a pol- 
icy existed but it just was not signed, to be honest with you, I can’t 
speak to the specifics of every situation. But the purpose of a policy 
is very profound. A policy demonstrates an organization’s commit- 
ment to perform a certain way. In the absence of policy which says 
this is how we are going to operate in this organization, then peo- 
ple are left to their own devices. And people left to their own de- 
vices go off in different directions, all with good intentions, and ar- 
chitecture is designed to get people all marching in the same direc- 
tion. 

Mr. Putnam. Is there some deadline when that policy was sup- 
posed to be in place by, Ms. Evans? 

Ms. Evans. No, we did not establish a specific deadline that said 
all agencies have to have a policy. As a matter of fact, I believe 
that was one of the suggestions that GAO had offered, that we 
should send a letter out enhancing that and advising going forward 
on that. That was one of the suggestions going forward, because 
there wasn’t specific guidelines out there saying every agency 
needs to have a policy in place. 

But I would like to followup a little bit on that and say that I 
don’t disagree with the way that the GAO model is set up in ensur- 
ing that the basic tenets of a good program are in place. I would 
like to say, though, that you have to take both of those into consid- 
eration to really see if an agency is truly using enterprise architec- 
ture to go forward to manage its portfolio. And so we are not here 
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to debate whether the GAO maturity model and framework is a 
good one or a bad one, because it is based on the tenets of the CIO 
Council as well, a framework that came out of the CIO Council, but 
what we are saying from an 0MB perspective is that — and this is 
another recommendation that came from the GAO report as well — 
is that we had to exercise even more oversight and more guidance 
out to the agencies. And that is the reason why we came up with 
the assessment framework from our perspective, too, because then 
it compliments what GAO is doing, so that you can then look at 
it as if, well, OK, if the policy is in draft, then it is going through, 
but yet they have all the other tenets there and they have the ca- 
pability and they are using it, then you can use the two frame- 
works to really get a handle on how an agency is moving forward 
and how mature that process really is, and is it really embedded 
into the strategic planning going forward. 

Mr. Putnam. I don’t want to harp on this and punish Ms. Nelson 
for being candid, but it just seems like the policy ought to be first 
base. How do you do all the other stuff if you don’t have the leader- 
ship from the top? That is what we harp on in every one of these 
hearings, is getting leadership from the top. And if you all are al- 
ready doing these things, it sure seems like having a policy signed 
and in place by the agency head or the department head ought to 
be one of the first things that is done just to get them committed, 
the name on the dotted line, and get them invested. 

Ms. Evans. I would just like to comment one further point on 
this. The policy itself isn’t so much about do you have an enterprise 
architecture in place and are you doing certain things. The policies 
and the guidelines that come out from 0MB are based on the te- 
nets that are in the Clinger-Cohen Act and in the E-Gov Act, talk- 
ing about overall management of the portfolio and how you are 
moving forward with your capital planning. 

Now, if you have a good mature capital investment planning pro- 
gram, then that means you have a modernization blueprint which 
is your enterprise architecture. So that is the point that I am mak- 
ing, that this is not a new thing that the agencies had to do. So 
when we talk about the details there, the agencies do have policies 
and plans in place of how they manage capital investments, and so 
those are in place, those have been signed by the agency heads 
going forward. 

Additionally, what we have done to bring this to the agency in 
holding an agency accountable is this is specifically included in the 
President’s management agenda and in the scorecard under the E- 
Gov element. So for an agency to be able to go ^een, this is a 
green criteria; that you have to have your enterprise architecture 
in place, you have to have that modernization blueprint in there, 
and you have to be using it. And so that is how we are holding the 
agencies accountable in that manner through the scorecard. 

Mr. Putnam. So there is a direct connection, then, between your 
at-risk status and the EE A initiative. So you use this scoring mech- 
anism to decide whether they are making progress or made 
progress on the FEA? 

Ms. Evans. We actually use a combination. And so we have our 
own assessment model, and actually what we do, and you would 
recognize it, we put up a quadrant when we meet the agencies and 
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we map our assessment score against the GAO assessment score, 
and the agency falls into a quadrant. I would be glad to give you 
a draft, in essence a report that we provide each agency as we go 
forward so that they can see how we are looking at their architec- 
ture efforts in concert with how they showed up in the GAO report, 
and then we go into a detailed assessment based on criteria that 
we have developed; and then we show them, based on all of that, 
how many of your investments aligned to the BRM, we give them 
very specific information about where we couldn’t see clear align- 
ment of investments and we give them the number, and then we 
also give them very specifically a list of investments that look like 
they are duplicative to us, getting back to your original comment. 
So we give them a whole huge package so that they can look at it. 
And we can give you a draft of this report, a representative sample 
of how we are doing that. 

Mr. Putnam. I don’t think I want to see. I don’t even understand 
the Cliff Notes version you just gave me. 

Ms. Evans. Well, what happens is that we take this and we take 
our assessment and we map it on a grid, and there is a maturity 
model associated with it. And then, with all the other tools that we 
have in place, we look at, OK, if this isn’t in place, there is a series 
of documents that we look through based on the submission, what 
they were required to do. So what will happen is if they don’t 
have — I mean, the best way to do this is if they don’t have enough 
information for us to even assess it, we show them what we are 
doing with the other agencies and it is marked DRAFT all the way 
across, which then that means they don’t have the checkmark on 
the scorecard that says that they have a modernization blueprint, 
which then that pretty much drives down, it is a cascading effect 
to all the other things that are going on that they are being meas- 
ured for of how they do their overall portfolio. 

So if you have an agency who is just trying to get checkmarks, 
which means that they may have a group of people who are work- 
ing on filling out paperwork for business cases and another group 
that is trying to fill out the paperwork so they can get their check- 
marks for enterprise architecture, when you pull it all together, 
you can see that is why they have at-risk investments, that is why 
they don’t have a good cyber security program, because they are 
just trying to get the checkmarks going forward. 

Mr. Putnam. Mr. Matthews, do you understand the system? You 
have to live with it. 

Mr. Matthews. Yes, sir. 

Mr. Putnam. Ms. Nelson, do you understand it? 

Ms. Nelson. I believe so. Karen and I are meeting on Friday to 
go over this, so I am sure I will have a fuller understanding on Fri- 
day. 

Mr. Putnam. Well, bring your quadrant paper. If you all under- 
stand it, I am happy. I mean, I think that is great. I just get a little 
bit nervous about all the different ways that we grade things. A le- 
gitimate complaint about things is that we are always changing the 
rules of the game. So as long as the folks having to do this under- 
stand the rules of the game and what they are being held account- 
able for, I think that is wonderful. But if she thinks she is a three 
and GAO thinks she is a one, I don’t know which quadrant that 
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puts her in, maybe she is a two, but it does get a little confusing, 
at least for the slow learner in the crowd who is sitting in this 
chair. 

Ms. Nelson. Can I clarify? 

Mr. Putnam. Please. 

Ms. Nelson. I do want to say, and I think hopefully it came 
across before, I support the measures that GAO has in place. And, 
in fact, in conversations with our own architecture committee and 
our chief architects, I said we need to accept these. This isn’t about 
disagreeing with these, because these are accurate, these are right. 
All I was trying to do is point out, though, that the numbers on 
the surface can be deceiving, because you can get up to 20 here. 
There are about 32 things you get ranked on, and if you miss one 
of those, you could be stage 4 or stage 1, depending on what you 
miss. So that is why I am just suggesting delve down one layer to 
see which one an agency is missing and how significant is that. 

It is also important that the GAO model really measures matu- 
rity. And that is a little bit different than what 0MB is measuring. 
So while they are different, that is OK, as long as the people who 
are using them understand the difference. And those of us who are 
using them, I think we do understand the difference. As I said, we 
just did our own self-assessment using the 0MB model, and I think 
we are close to a level 3. You don’t want to confuse those because 
they are measuring different things. 

Ms. Evans. Let me try one more time. But when you map the 
two of those together, because it is the question that you are ask- 
ing. OK, you get an assessment from GAO and it is saying, for ex- 
ample, let us take EPA, and it says it is a one. Then we have a 
tool that says, oh, they are a three. So the natural question is, well, 
what the heck is that and why are you measuring two separate 
things. Well, we are trying to then give you a view into, OK, they 
may have the basic tenets, you Imow, they may be practicing 
things very well, but they don’t have the core of what they need 
to have a sustaining practice beyond the current people that are 
there. So that is why we tried to put it in a framework that an 
agency could look at it. 

So if you took a one and a three, based on these two, they would 
show in the quadrant that is growth, which means that they have 
the potential to continue to grow in EA competencies, which would 
definitely show that there is a difference there and that commu- 
nication needs to go forward; that it is definitely not a best of breed 
there. 

Mr. Putnam. Room for growth. Seems like my junior high report 
card. Room for growth. 

I apologize if I have dragged this into the weeds. 

Mr. Hite, do you have any comments that you would like to leave 
us with before we move to panel two? You started all this. 

Mr. Hite. Yes, sir, if I could offer a couple of comments on what 
we have been talking about so we can get further into the weeds, 
one of which is that I would be willing to accept on behalf, for you, 
what Karen asked to share with you, because I would be very much 
interested in seeing those results. 

But let me also say that when we did this framework, we didn’t 
believe that it is going to be the end-all and be-all, the one measure 
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that is going to tell you everything you want to know about 
progress in enterprise architecture. One of our motives was that it 
is not being measured now at all, so let us get a measurement tool 
out there. But we also recognize that it measures a particular 
thing: it measures the maturity of the management process. It is 
a process framework. It does not measure maturity of content of 
the architecture, for example. That is a whole different set of cri- 
teria. So we believe that there needs to be multiple measures. 

Now, I haven’t looked at the specific one that Ms. Evans is talk- 
ing about, so I can’t comment on it particularly, but I can say that 
I support the idea of multiple measures so that you get a clearer 
picture of where an agency is in this very important area. 

Mr. Putnam. How many people work in GAO’s IT division? 

Mr. Hite. Rough number is 160 to 165. 

Mr. Putnam. Isn’t it fun having 165 people checking out every- 
thing you do, Ms. Evans? 

Ms. Evans. Yes, it is. 

Mr. Hite. Well, I would like to also add that I have about six 
looking at enterprise architecture across the entire Federal Govern- 
ment. 

Mr. Putnam. Well, we haven’t really cracked any heads or any- 
thing over what is on this chart, and I think now that we are 
digging in, there are good reasons for doing that. But I think that 
you can generally say, looking at the trend, for whatever falls are 
in your scoring mechanism or in the grading content, the trend 
isn’t real high. 

Mr. Hite. Absolutely. 

Mr. Putnam. I mean, you have 76 in stage 1, nobody in stage 4, 
and 1 in stage 5. 

Mr. Hite. Well, this one over here shows you the actual trend. 
This shows you if things have gotten better since they were in 
2001. And that is comparing against the same version of the frame- 
work. 

Mr. Putnam. I think that is the overarching lesson here, without 
digging down into exactly what the content was. The bottom line 
is we have a long way to go. 

Mr. Matthews. 

Mr. Matthews. Mr. Chairman, one thing that I wanted to men- 
tion on the 0MB version, there are certain criteria in each one of 
those stages, and while an agency may be working at satisfying cri- 
teria in stage 2 and 3, and they don’t have, as Ms. Nelson pointed 
out, a signed document from the Administrator of the Secretary’s 
office, it would reflect them as being in stage 1 until such time as 
they had that document, even though they had satisfied everything 
in two, three, four, and five. Perhaps when we report, an acknowl- 
edgment that certain criteria are being met in other categories 
would be a better indication of an agency’s growth along that 
framework path. Certainly agencies need to have senior manage- 
ment support, but the true measure of the work that is going on 
is how many of those criteria are being met from year to year. 

Thank you, sir. 

Mr. Putnam. Ms. Nelson is going to go camp out in front of the 
administrator’s door and hold him down until he signs her paper. 

Ms. Nelson. 
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Ms. Nelson. I have the pleasure of having an administrator, 
Mike Leavitt, who gets it, who understands enterprise architecture. 
In our very first meeting he raised and used those words, so we 
will get it done. But I concur with Mr. Matthews, because an inter- 
esting chart for you to look at maybe is to see if you take the 32 
items or characteristics we are being measured on for maturity, 
how many agencies answered yes to those characteristics in stage 
4, stage 5, stage 3, stage 2? Because you are going to see a lot way 
out there in four and five, and the question becomes some people 
believe you can’t get to four unless you do every single thing in 
three. I disagree with that. I think in order to really truly sustain 
it for a long period of time that may be necessary, but I think you 
can gradually move into higher levels of stages, because it is not 
a perfect world. And it might be interesting, as Mr. Matthews said, 
to look out and see how many people do have yeses in threes and 
fours and five. It just gives you a slightly different picture. We still 
need to do everything GAO said. I agree wholeheartedly we have 
to do it. But it is a slightly different picture or perspective on the 
same situation. 

Mr. Hite. I would agree that is a relevant thing to look at and, 
in fact, we looked at that. So we looked at the performance of core 
elements between 2001 and 2003, regardless of what stage they 
were in, and basically we found that — I can’t remember the exact 
numbers, but this is the rough figures. I think it was something 
like 57 percent of them were being performed or 47 percent were 
being performed in 2001 and 53 percent of them were being per- 
formed in 2003. So if you even look at core elements, regardless of 
stage, there wasn’t much change between 2001 and 2003. 

Mr. Putnam. Fifty-three percent is an F in most places. 

Ms. Evans, do you have any final thoughts? 

Ms. Evans. Well, first and foremost, I would like to thank you 
for having the hearing today on the Federal Enterprise Architec- 
ture, as well as giving the agencies the opportunity to talk about 
their enterprise architectures. As you can see, this is going to be 
a continuous challenge just based on the dialog that we were hav- 
ing today, and how we are using it to continue and manage overall. 
But I think the big key is to really realize that this isn’t really just 
an IT tool, and that the CIOs, yes, are chartered to do it and we 
have mapped it to do things with the IT investments, but this real- 
ly is a management tool, and it is a strategic management tool. 
And I have been able to answer questions very quickly and very 
rapidly for my management by saying, yes, I know what agencies 
are in this area providing this type of service and, oh, by the way, 
I do know how many dollars are being invested in IT this way. We 
may not necessarily talk about the models, and you can see when 
you start getting down to a certain level here we have to start talk- 
ing the same language, and technical people go off in one direction 
and management people go in another, but the key here is that this 
tool and a hearing like this raises it to a level where we then can 
talk about it and start going down that path. So I would like to 
commend you and thank you for having this hearing today for us. 

Mr. Putnam. Well, thank you, and you all keep working on it. 
We have a long way to go, but it is very important, and we appre- 
ciate the work that you are doing on it. 



86 


The committee will stand in recess for a couple of moments while 
we arrange for the second panel. 

[Recess.] 

Mr. Putnam. The subcommittee will reconvene. 

I would like to welcome our second panel of witnesses and ask 
that you please rise and raise your right hand, along with any oth- 
ers who may be accompanying you for the purposes of providing in- 
formation to the subcommittee. 

[Witnesses sworn.] 

Mr. Putnam. Note for the record that all the witnesses re- 
sponded in the affirmative, and we will move immediately to their 
testimony. 

Our first witness for the second panel is Dr. Dave McClure. Dr. 
McClure is the vice president for E-Government with the Council 
for Excellence in Government. In that position. Dr. McClure serves 
as the strategic leader of the Council’s E-Government Information 
Technology programs, developing strategies with public and private 
sector leaders to use information and communication technology to 
improve the performance of government and engage citizens. Dr. 
McClure is also involved in many of the Council’s intergovern- 
mental partnerships and helps runs the E-Government Fellows 
Program. 

Prior to joining the Council in 2002, Dr. McClure was the Direc- 
tor of Information Technology Management Issues at GAO. As a 
member of the SES at GAO, he conducted governmentwide evalua- 
tions of IT investment and performance measurement issues, mon- 
itoring agency implementation of IT management improvement ef- 
forts, evaluating the progress being made with E-Government ini- 
tiatives, and reviewing agencies’ IT work force planning strategies. 

In 1998 and 2001 and in 2004 he was named one of Federal 
Computer Week’s top 100 IT executives in the Federal Govern- 
ment. 

Welcome to the subcommittee. You are recognized for 5 minutes. 

STATEMENTS OF DAVID MCCLURE, VICE PRESIDENT FOR E- 
GOVERNMENT, COUNCIL FOR EXCELLENCE IN GOVERN- 
MENT; VENKATAPATHI PUWADA, UNISYS CHAIR, ENTER- 
PRISE ARCHITECTURE SHARED INTEREST GROUP, INDUS- 
TRY ADVISORY COUNCIL; NORMAN E. LORENTZ, SENIOR 
VICE PRESIDENT, DIGITALNET; AND RAYMOND B. WELLS, 
CHIEF TECHNOLOGY OFFICER, IBM FEDERAL, VICE PRESI- 
DENT, STRATEGIC TRANSFORMATIONS FOR IBM SOFTWARE 
GROUP, APPLICATION INTEGRATION & MIDDLEWARE DIVI- 
SION [AIM], IBM CORP. 

Mr. McClure. Thank you, Mr. Chairman. It is a pleasure to be 
here. As you noted, my organization, the Council for Excellence in 
Government, has been dedicated for more than 20 years to helping 
achieve high-performance government and increasing public par- 
ticipation and confidence in government. 

I think it is very important that we not lose the citizen perspec- 
tive in the discussions that we have today. Our national polls and 
some of the homeland security town halls that we have had around 
the country recently show that the public wants a government that 
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is accountable, simple, convenient to interact with, and accessible 
through the means of their choice. 

The FEA provides some important tools for defining and provid- 
ing this streamlined, simplified citizen-centric government to the 
American public. 0MB has provided a crisp analysis of the Federal 
Government as it is and has offered a strong vision of where it can 
be. The common program, business and service delivery patterns of 
government are presented with clarity and help reveal the complex 
overlapping and often duplicative nature of its interactions with 
citizens and businesses. 

The FEA approach follows leading-edge commercial practice. 
Many Fortune 500 companies are using similar approaches to bet- 
ter align their technology with business process needs. They have 
recognized that IT is more than just building and running systems. 
Enterprise architecture approaches “tune-up” organizations, focus- 
ing on management of information as a core asset, and emphasiz- 
ing component reuse rather than the constant “scrap and build” 
that we have had in the past. 

The FEA is not defining a single architecture for the entire Fed- 
eral Government. Rather, it assembles the assets and the tools that 
can provide cross-agency analyses, identification of performance 
gaps, and opportunities for better alignment of resources. It is not 
static; it will change and it will evolve as technologies change. 

We must stay this course with the FEA. The payoff for the Gov- 
ernment simply can be huge. Not only can this help achieve cost 
savings and performance improvements, but it also can grow the 
public’s confidence, trust, and satisfaction with Government itself 

Let me touch on three important challenges that lie ahead. First, 
we have to proceed with disciplined maturity and alignment. We 
have to make some sense of the many moving pieces of Govern- 
ment programs, policies, and services, and the enterprise architec- 
ture approach is a valid tool for doing that. But we have to get 
agencies up to par. GAO’s audit work, using its widely endorsed EA 
Assessment Framework, reveals this very mixed progress in the 
pace, speed, and direction of the EA work taking place in the Fed- 
eral Government. 

The good news is that there are a lot of bright spots. GAO’s ag- 
gregate or top line numbers, as you have seen on these charts, 
while maybe disappointing, tell only a partial picture. Many agen- 
cies are actually doing things at higher maturity levels but cannot 
be tagged that way because they are not performing completely at 
lower levels. Several of these agencies, by the way, Mr. Chairman, 
are on the verge of getting fives on GAO’s scale. 

But putting agency-centric architectures in place really stops 
short of the larger governmentwide transformation that EA can 
help create. We need both vertical alignment of goals, processes, 
and technology within agencies, and, where possible, horizontal 
alignment across common governmentwide functions and processes. 
There is a lot of work to be done in both of those areas. 

My second point is about the “so-what.” It makes sense that 
those that determine budgets should see measurable impact from 
the time, cost, and energies that we are putting into enterprise ar- 
chitecture approaches. They are many that come to mind: stream- 
lined and simplified processes, greater systems interoperability 
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that facilitate the exchange of information, faster application deliv- 
ery, and enterprise licensing opportunities, just to mention a few. 

These are important. They have real dollars attached to them. 
When combined with measuring and scoring the EA capability ma- 
turity, the measures provide a fact-based assessment of capacity, 
capability, and results. These measures are necessary, but by 
themselves I don’t think are sufficient. The real high value return 
from enterprise architecture are those that capture the impact on 
direct mission-related performance, whether that be saving lives, 
protecting the environment, inspecting the food supply, or identify- 
ing and deterring terrorist threats. Better EA should translate into 
time, cost, and quality improvements in government, and we can- 
not lose this line of sight. 

A final key challenge is leadership. Enterprise architectures re- 
quire commitment and participation from top leadership, beginning 
with the heads of agencies and program executives all the way 
through the CIO, CFO, and procurement officer communities. It 
cannot be the sole purview of CIOs and CTOs. 

In this vein, I think it is imperative that OMB’s vacancy in its 
chief architect position be filled carefully and very expeditiously. 
This person is the most visible spokesperson for architecture in the 
Federal Government, and directs the FEA work, and also supports 
program assessments and business case reviews in the 0MB budg- 
et cycle. We need a credible, experienced individual with strong 
outreach, collaboration and communication skills. That person has 
to translate a lot of the jargon of EA into something that is under- 
standable to non-technology managers and executives, and it is a 
very, very important job. 

So we need continued focused leadership from 0MB. We also, 
Mr. Chairman, need to extend this dialog on the Hill beyond this 
committee and into the Budget, Appropriations, and Authorizing 
Committees of the Congress. Enterprise architectures offer great 
hope both as engines of change and instruments of sorely needed 
management controls over orderly government transformation. 
Transparency, accountability, and results that translate into better 
Government for the American public should be front and center in 
all of these efforts. 

Thank you, and I look forward to your questions. 

[The prepared statement of Mr. McClure follows:] 
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Mr. Chairman and members of the Subcommittee, thank you for inviting 
me to appear before you today to discuss progress being made by 0MB and 
federal agencies in developing and implementing enterprise architectures. 

As you may know, the Council for Excellence in Government is a non- 
partisan, non-profit organization that has been dedicated for more than 20 years 
to helping government improve the quality of its performance and to increase the 
public's participation and confidence in government. We work to catalyze reform 
in government by providing forums for citizen engagement and building bridges 
between industry best practices and the desired goal of high performance 
government. We applaud the work of this Subcommittee and your leadership in 
providing essential congressional oversight focused on the measured progress 
that 0MB and the agencies are making in using technology to enable high quality 
and cost effective services to the public. 

As demonstrated by our regular national public opinion polls and most 
recently our Homeland Security town halls around the country, citizens want 
government that is accountable, convenient, easy to navigate, and accessible. 
The Federal Enterprise Architecture developed by 0MB over the last two years is 
an essential element in defining and providing streamlined and simplified 
government to the American public. 

In its simplest form, the FEA is comprised of five basic reference models 
that focus on; 

• Defining functional lines of business that describe the business operations 
of the federal government independent of the agencies that perform them 
(fhe Business Reference Model), 
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• Measuring the performance of major IT investments and their contribution 
to line of business and agency program performance (the Performance 
Reference Modef), 

• Identifying reusable software applications, process automation services, 
business management services, transactional services, and customer 
services on a government wide basis (the Service Component Reference 
Modef), 

• Describing the data and information used in interactions and exchanges 
that support program and business line operations throughout government 
(the Data and Information Reference Modef), and 

• Identifying the standards, specifications, and technologies that support the 
construction and exchange of service components that can be leveraged 
in component-based or shared services-oriented architectures (the 
Technical Reference Modef). 

The FEA also provides an important foundation for the President’s 
Management Agenda and its goal of achieving electronic government, financial 
management, performance and budget integration, and human capital goals. 

The FEA has provided crisp analyses of government “as it is” and offered a 
vision of where it can be - showing with amazing clarity and reality the program 
and business patterns of government. 

This process has identified unparalleled opportunities to eliminate 
unnecessary overlap, redundancies, and inefficiencies in how citizens, 
businesses, and government employees interact with government and the 
programs and services it delivers. Why, for example, would government require 
businesses to submit virtually identical information to the federal government 
through dozens of different processes, different forms, and with varying degrees 
of efficiency? Why would we have over two dozen major payroll systems that 
perform the same basic function but with enormous variances in cost per 
transaction? The work underlying the FEA has provided unparalleled 
transparency into how the federal government operates. Moreover, performance 
outcomes and budget decisions can be more tightly linked using the FEA 
frameworks as guideposts. 

The FEA effort itself - focused on using basic reference models for 
defining and aligning federal business functions and its supporting IT - 
represents leading edge practice. Only a handful of large companies have this 
kind of reference framework in place and other countries around the world 
astonished at the process used and its deliverables to date. The key to this 
progress has been focused leadership from OMB, disciplined controls, and a 
dedicated partnership between government and industry to make it happen. 

Nonetheless, make no mistake: This difficult endeavor is full of challenges. 
The goal is not simply to provide a single, overarching enterprise architecture for 
the entire federal government. Rather, the FEA seeks to facilitate cross-agency 
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analysis and identification of duplicative investments, performance gaps, and 
opportunities for cross-agency collaboration on similar activities. The work in the 
trenches is far from finished and we find ourselves at a critical crossroads. We 
must stay the course if we expect to use the frameworks to bring cost efficient 
and effective service delivery to the public. It will require constant focus, 
disciplined management, and executive leadership, and a willingness to accept 
improvements along the way. The payoff can be huge for government 
performance improvement in terms of identifying opportunities to re-use and re- 
deploy IT assets across the government. Not only can this help achieve cost 
savings; it can also grow public confidence, trust, and satisfaction with 
government itself 

In my remarks today, I want to focus on three critical challenges related to 
the future of enterprise architectures in the federal government: (1 ) ensuring 
disciplined agency architecture maturity and alignment, (2) concentrating on 
tangible outcomes and measures of impact, and (3) providing continuous, 
focused leadership. 

Let me begin with disciplined maturity and alignment. There are simply 
too many moving pieces within and across the federal government’s myriad of 
programs, policies, and services to manage without enterprise architectures in 
place. Government programs have grown up over time, responding to time 
sensitive needs, crises, and public demand. Enterprise architectures provide a 
disciplined means to map the “business” of government and its corresponding 
data, information flows, and processes. It can bring visible structure and rigor to 
understanding what an organization does and the work processes, data, and 
technology which is attempting to enable mission outcomes. 

There is good news in that several methodologies, tools, and assessment 
frameworks are available to agencies. For example, to assist in analyzing and 
benchmarking agency maturity in putting core elements of enterprise 
architectures in place, GAO has also created its own Enterprise Architecture 
Maturity Model Framework. There is a great deal of consensus in the federal IT 
community on the framework's value in providing a thorough, comprehensive 
assessment of agency EA progress. Its focus on performance and security, 
metrics for measuring EA development, quality, and use, and recognition of the 
need for using accepted EA methodologies, combined with independent 
verification and validation, are strong points. Additionally, OMB has created a 
web-based management system to help discover components, business 
services, and capabilities across the federal government. OMB has also recently 
augmented this with its own Enterprise Architecture Assessment Framework. In 
short, we don’t have a shortage of models, guidance, tools, and assessment 
processes. 

The key is ensuring that agencies design and implement their 
architectures using foundational principles and management processes identified 
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in the methods, tools, and assessment frameworks. Over the decades, the 
federal landscape is strewn with sizeable and costly efforts to define enterprise 
architectures. Most have been little more than abstract, paper product drills that 
have not been complete or never moved into real implementation and 
enforcement with corresponding management processes and executive 
oversight. The GAO assessment framework provides an invaluable way to 
examine real progress and maturity based on the best of available commercial 
and public sector approaches. 

We must get federal agencies up to par in order to deliver cost effective 
and high performance government services to the public. As GAO has reported, 
current agency progress in designing and implementing enterprise architectures 
is mixed at best. On its maturity scale ranging from one to five, average agency 
maturity has hovered around 1 .75 for the last three years. As noted in GAO's 
recent government wide assessment, only 22 agencies increased their maturity 
stage, while 24 declined and 47 remained the same. Still, there are bright spots 
of progress and maturity as illustrated by efforts at Veterans Affairs, EPA, OPM, 
HHS, Treasury, DOD, IRS, and the Executive Office of the President. Lack of 
top management understanding and commitment and of maintaining adequate 
funding levels for EA development, plus the absence of skilled staff and simple 
parochialism, offer significant challenges thwarting continuity of design efforts 
and implementation. Without continued emphasis on disciplined approaches and 
follow-up management commitment, progress will remain difficult. 

But putting agency centric enterprise architectures in place stops short of 
the true transformation they can help create. We must have both vertical 
alignment within agency boundaries and horizontal alignment across common 
functions and business processes of government. As we move forward, it is 
imperative that agencies construct architectures that are aligned with the FEA 
and its push toward process and systems consolidations. The FEA provides a 
true "portfoiio” view of government programs, processes, and investments. 
Moreover, it offers a viable, collaborative way to analyze and approve budget 
requests that surface from agency-centric ways of doing business. Integrating 
enterprise architecture work with IT capital planning and investment decision- 
making, and ultimately performance and budget reporting, should be the norm, 
not the exception. 

Let me turn to the “so what” of using enterprise architectures. We must 
see measurable impact on performance or a return on investment from the time 
and effort required to design, implement, and manage architecture efforts. 
Traditionally, enterprise architectures are valued for their ability to: 

• simplify and streamline processes and the supporting technology 
infrastructure, 

• achieve greater levels of interoperability and thus enhanced data sharing 
capabilities, 

• increase flexibility in adapting to technology change. 
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• deliver applications and systems faster and more cost effectively, 

• reduce the overall cost of technology support by eliminating systems 
redundancy, duplicative data storage, and re-use of application 
components, 

• align technology tightly with business^^rivers and needs, 

• deliver systems on or ahead of schedule, and 

• maintain highly reliable, dependable IT service levels. 

Measuring compliance with proven methodologies and approaches is one 
way of determining whether process maturity is occurring. This kind of 
performance reporting and feedback is valuable and necessary, but by itself not 
sufficient. Being able to demonstrate productivity gains, cost improvements in 
the delivery of IT, and cost savings from systems consolidation and component 
or application re-use are equally important tangible measures of return. 

But “real” returns are those that measure impact on direct mission related 
performance. If architectures are done well, we should expect visible changes in 
program or service delivery outcomes. For example, if DHS can demonstrate 
through its enterprise architecture efforts that it is able to identify homeland 
security threats in minutes or hours rather than days or weeks, then real change 
has occurred. Similarly, if an industry can submit the same registration or 
regulatory compliance information on-line once to government rather than 
numerous times to many agencies in different formats, then lower administrative 
costs and internal productivity gains to the industry are also a very real impact 
from the associated reduction in the reporting burden. Further, if social security 
or veterans’ disability claims can be resolved in hours or days because of people, 
process, and technology improvements that minimize unnecessary data 
collection and get the right information to claims specialists in a timely, reliable 
manner rather than taking months or Herculean efforts, we have truly achieved a 
real return on investment. 

This brings me to a final key point. Enterprise architecture work requires 
leadership and executive understanding, commitment, participation, and constant 
attention. This work cannot be the sole purview of CIOs and their staffs. The 
front pieces of the Business Reference Model, the Performance Reference 
Model, and the Service Delivery Models have to be co-led by the business or 
program divisions. Governance structures and decision processes must be in 
place to make this a reality. 

One of the most pressing leadership needs confronting us now is filling the 
position of the Chief Architect in OMB’s Office of eGovemment and Information 
Technology. Progress is in a perilous position as long as this position remains 
unfilled. This individual leads the important work of the FEA Program 
Management Office and is the most visible spokesperson for architecture work in 
the federal government. This void comes at a time when the remaining Data 
Reference Model is being finalized and vetted within government. The person 


5 



94 


chosen for this important position must be a credible, experienced authority in 
enterprise architecture development and implementation and provide 
government wide direction to the continuing development, guidance, and 
oversight of the FEA and agency architectures. 

More importantly, the Chief Architect position requires someone with 
strong outreach and communication skills. The individual must translate the core 
value of using enterprise architectures as a means of controlling IT investments 
and achieving cross-agency service delivery synergies essential to achieving 
high performance government. Working collaboratively with chief architects in 
the agencies, this individual must engage in constant, constructive dialogues with 
agency heads, program executives. Chief Financial Officers, and the Congress. 
We urge the Administration to move with careful but expedient consideration in 
making this important selection. 

The chief architects serving in agencies across the government must also 
work as a collaborative, cohesive force and be equally engaging with non-IT 
executives. Importantly, this group recently convened its first government wide 
forum to network and exchange ideas. The Council is working to ensure that this 
forum continues as a means of identifying best practices, lessons learned, and 
conducting broad outreach and problem solving. The Chief Architect is a natural 
leader for this group and its cause. 

In conclusion, Mr. Chairman, having enterprise architectures in place in 
government is paramount to achieving real performance outcomes. They are 
engines of change and instruments of sorely needed management control over 
orderly transformational changes. As we move forward, transparency, 
accountability, and results that translate into better government for the American 
public should be front and center, 0MB must continue to exercise strong 
government wide leadership, working collaboratively with agencies but 
maintaining vigilance in its budget and accountability oversight. Agency leaders 
must involve themselves in enterprise architecture governance and evaluate 
progress and performance results. Lastly, it is imperative that the dialogue 
extends beyond this Subcommittee and into the agendas of the budget, 
appropriations, and agency oversight committees of the Congress. 

Thank you. 
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Mr. Putnam. Thank you, Dr. McClure. 

Our next witness is Mr. Venkatapathi Puvvada. Mr. Puwada 
serves as Chair of the Industry Advisory Council, Enterprise Archi- 
tecture Shared Interest Group, and works closely with the CIO 
Council, Office of Management and Budget, and other Government 
agencies in that capacity. Mr. Puvvada co-founded the EA SIG in 
2002 to address the need for industry and government partnerships 
to help bring industry best practices and expertise together in a 
common forum. The lAC EA SIG is comprised of over 200 practic- 
ing architects and executives from over 100 companies. 

That is harder to say than your name. 

Mr. Puvvada was recognized with the prestigious Federal 100 
Award in 2003 for his contributions and impact on the direction of 
IT in government. For more than 18 years, Mr. Puvvada has 
worked in information systems, 16 years of that with Unisys. In 
addition to serving as the chair of the EA SIG, Mr. Puvvada is the 
chief technology officer of Unisys Global Public Sector, as well as 
the vice president and partner for Unisys Worldwide Enterprise 
Architecture Solutions Services Practice. The Unisys EA Solutions 
Practice consists of world-class enterprise solution architects that 
develop and implement architectures for clients such as the TSA, 
the GSA, the DOD, the VA, the FDA, and several State govern- 
ments. 

Welcome to the subcommittee. 

Mr. Puwada. Thank you, Mr. Chairman. We will try to simplify 
these acronyms next time around. 

Thank you for inviting me to speak today. I am really honored 
to be here representing Industry Advisory Council [lAC], and I 
would like to acknowledge some of my colleagues that are here for 
their hard work and their passion to improve architectures in the 
government in the truly excellent way that they represent 400 
member companies of lAC. 

In terms of our work, before I get into the details of the testi- 
mony, our recommendations and best practices have been success- 
fully published in the form of five white papers, and they have 
been widely recognized for their innovative insight, and the details 
are included in my written testimony. 

In our view, enterprise architecture is the only practical way on 
a consistent basis for comparison of investment decision by agency 
executive leadership. Private sector experience suggests that the 
proper development and usage of EA can lead to a major trans- 
formation of an organization, its processes, and its performance. 

As for commenting on the progress of the FEA initiative, the de- 
velopment of the interlinked reference model allows the Govern- 
ment to have an enterprise view of its business for the first time. 
As a result of the progress on FEA, we acknowledge significant im- 
provements in the way the agencies conduct the quality and the as- 
sessment of their budgets and the preparation of the budget proc- 
ess. Various departments and agencies are also making good 
progress in allowing their enterprise architectures in the context of 
the Federal Government and FEA. EA products are effectively used 
by several CIOs as decisionmaking framework in the capital plan- 
ning portfolio management and general IT governance. Therefore 
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we rate very high marks for the blueprint for improved IT invest- 
ment management aspect of the hearing, Mr. Chairman. 

However, major hurdles exist for cross-agency collaboration and 
information sharing aspects. Some of these challenges are as fol- 
lows. First one is lack of sufficient positive incentives for agencies 
to collaborate and have common business process integration and 
secure information sharing. The second one is lack of sufficient 
funding and key resources, especially chief architect of the 0MB, 
as Mr. McClure referred to, and the skills in the context of busi- 
ness architecture skills to lead and implement this transformation 
at the department level, as well as the Federal level. Also, the Gov- 
ernment needs to move the FEA and EA as a high priority trans- 
formation mechanism for the owners business and mission program 
so that it doesn’t turn out to be a technical exercise for architects 
and the CIOs. 

Going forward with the EEA and the agency EA, we believe time- 
ly completion and implementation of the data and information ref- 
erence model is very important. The ability of the Eederal Govern- 
ment agencies to understand and map to each other’s data through 
the use of a common model is a major factor in achieving the cross- 
agency collaboration, information sharing and data interoperability, 
along with some quick success pilots. Development and implemen- 
tation of the big 10 enterprise security and privacy architecture, as 
referred to earlier by Mr. Hite, that is integrated into all layers of 
EA is very critical as well. 

Mr. Chairman, industry really appreciates your commitment, 
your committee’s commitment in getting involved as a major stake- 
holder in this initiative. We believe that the articulation of legisla- 
tive priorities and activities in the context of EEA are really perti- 
nent in advancing the maturity of business-driven IT solutions that 
citizens are expecting. 

To summarize our view, lAC is very supportive of enterprise ar- 
chitecture initiatives as a major government priority and agrees 
with its general direction and recommends staying the course. 
There are a lot of challenges facing these initiatives, but they can 
be overcome with strong executive leadership, clear governance, 
and positive incentives for agencies to collaborate. We applaud the 
Government for reaching out to lAC and industry and leverage our 
expertise, and we are committed to continuing this support in fu- 
ture. 

Thank you for the opportunity to appear before you today, and 
I would be very happy to answer your questions. 

[The prepared statement of Mr. Puwada follows:] 



97 


WRITTEN STATEMENT OF 
VENKATAPATHI R. PUWADA (PV) 


CHAIR 

ENTEPRISE ARCHITECTURE SHARED INTEREST GROUP (SIG) 
INDUSTRY ADVISORY COUNCIL (lAC) 

AMERICAN COUNCIL FOR TECHNOLOGY (ACT) 


BEFORE THE 

COMMITTEE ON GOVERNMENT REFORM 
SUBCOMMITTEE ON TECHNOLOGY, INFORMATION POLICY, 
INTERGOVERNMENTAL RELATIONS, AND THE CENSUS 
U.S. HOUSE OF REPRESENTATIVES 


MAY 19, 2004 



98 


Good afternoon, Mr. Chairman, Ranking Member Clay, and Members of the 
Committee. Thank you for inviting me to speak about the “Federal Enterprise 
Architecture (FEA): A Blueprint for Improved Federal IT Investment Management & 
Cross-Agency Collaboration and Information Sharing.” 

My name is Venkatapathi Puwada (PV) and I am the Chief Technology Officer 
(CTO) for Unisys Global Public Sector. However, today I am honored to be speaking on 
behalf of the Industry Advisory Council (lAC) in my role as the Chairman of its 
Enterprise Architecture Shared Interest Group. Before I speak on our view of FEA, 
please let me briefly introduce lAC, its role, and activities. 

lAC is an advisory body to the American Council for Technology (ACT), a 
membership-driven nonprofit organization established in 1979 with the purpose of 
leading the Information Technology (IT) community to improve government. ACT 
facilitates and encourages education, communication and collaboration across all levels 
of government. 

ACT created the Industry Advisory Council in 1989, with the goal of working to 
improve communications and understanding between government and industry. Today, 
lAC is comprised of more than 400 private sector firms that provide information 
resources, management products and services to government. Our member firms include 
hardware manufacturers, software companies, systems integrators, consulting service 
providers, telecommunications companies and professional services companies, 
comprised of small and large businesses. 

lAC’s mission is to bring industry and government executives together to exchange 
information, support professional development, improve communications and 
understanding, solve issues, and build partnership and trust, thereby enhancing 
government’s ability to serve the nation’s citizenry. This is accomplished by providing a 
forum for the study and analysis of public sector management and technology issues, 
advising ACT on the possible impacts of industry trends on government technology 
issues, serving as a sounding board for changes to federal regulations, assisting in public 
relations and public affairs programs aimed at improving the health of government; and 
providing education and training to industry and government personnel. 
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Enterprise Architecture Shared Interest Group 

As a part of this mission, lAC established the lAC Enterprise Architecture Shared 
Interest Group (lAC EA SIG) because of the crucial role of Enterprise Architectures in 
achieving improved citizen services, cross agency information sharing and effective 
mission fulfillment as the Federal Agencies continue their transformation initiatives. lAC 
has collaborated closely with the Office of Management and Budget (OMB) Federal 
Enterprise Architecture Program Management Office (FEA-PMO) and the Architecture 
and Infrastructure Committee (AlC) of the CIO Council in an effort to extend, enhance, 
and enable the Federal Enterprise Architecmre (FEA). The lAC EA SIG is made up of a 
diverse range of thought-leaders, enterprise architects and solution architects with 
working knowledge and extensive experience in various aspects of architecture, IT 
governance and solutions implementation. Our focus and vision has been the following: 

• Purpose: Establish a forum for government and industry to identify and candidly 
discuss Enterprise Architecture and issues related to it. 

• Mission: Provide a practical implementation approach for utilization of the FEA 
Reference Models in alignment with the agency EA efforts. 

• Objective: Bring industry best practices in EA and identify opportunities to support 
Federal government partners in articulating and enhancing the value of architectural 
approach. 

As a part of fulfilling this mission, the lAC EA SIG successfully assembled industry 
best practices, views and experience into five white papers. The papers discuss the 
process, modeling, and implementation issues associated with the FEA and 
Department/Agency-wide EA. These papers are available at httD://www.actgov.ore . 

We are very pleased to report that this work has been widely recognized throughout 
government and industry for its innovative insights, in-depth analysis and suggestions for 
practical approach to enable implementation of FEA and achieve cross agency 
collaboration and interoperability. Brief summaries of these white papers are attached in 
Exhibit A for your convenience. Currently, lAC EA SIG is actively working with the 
Office of Management and Budget (OMB), CIO Council, National Association of State 
CIOs (NASCIO) and Federal Departments and Agencies in providing its views and best 
practices on a number of initiatives related to FEA and EA. This includes our efforts to 
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enable approaches for collaboration and information sharing across various boundaries of 
the government at Federal, State and Local levels. 

Mr. Chairman, on behalf of lAC, 1 owe a debt of gratitude to my lAC colleagues for 
their commitment and passion to help improve government by generously providing their 
valuable time, practical insights and expertise on their own initiative. I would also like to 
point out that most of our lAC EA SIG members are from small and medium businesses, 
bringing their iimovative ideas and unique perspectives to these issues. 

Enterprise Architecture: A Blueprint Analogy 

Most often EA has been construed as a technical exercise, probably because the 
underlying concepts and benefits are not articulated in simple business terms. To address 
this issue as well as to set the stage for this discussion, we would like to simplify the EA 
concepts, nature and value through an analogy that is easily understood and appreciated 
by non-teohnical users. 

Enterprise Architecture is very similar to the blueprints used everyday in county 
planning, community development, building design and construction. To deliver high 
quality of life for its citizens, this carefully planned and organized blueprinting ensures 
availability of common infrastructure, standards, codes, and processes resulting in 
economic vitality, collaboration and efficiency. 

• The county planning level blueprint (as akin to FEA), at a macro level, specifies the 
roadmap of its enterprise with policies, standards, budget processes, and 
governance through a common shared vision for its citizens. This blueprint also 
provides a mechanism for interconnecting various communities as well as a 
framework for common infrastructure. 

• The commimity level blueprint (as akin to agency EA) specifies the requirements, 
scope and the context of the community within its over-arching county blueprint. 
One is essentially zooming in on the details of a community needs, goals and 
transformational plans. This is typically done by the planners and policy makers by 
recognizing common design patterns and requirements; resulting in effective re-use 
of previously successful community architectures. 

• The individual building design blueprint (as akin to solution architecture for a 
business line or a system) provides the detailed drawings and specifications 
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(through a common notation) so that a builder can construct a building with 
accuracy, consistency and is able to connect to the common infrastructure as 
specified in the community level blueprint. When an inter-operable infrastructure is 
clearly specified and available for connection, a building owner does not invest in 
his or her own expensive and redundant infrastructure or component such as an 
electric/gas utility plant, water treatment facility, sewer system or a telephone 
exchange. This allows for a faster and cost-effective way to develop and construct 
individual buildings while still ensuring high quality. 

This analogy illustrates in very simple terms the value of Enterprise Architecture as a 
proven, carefully plarmed and collaborative method to achieve mission and business 
results consistently just as envisioned by the Clinger-Cohen Act and FEA. 

Need for Federal Enterprise Architecture 

In our view, FEA is very critical to the government to be able to achieve significant 
improvements in the way it conducts itself The development of department, agency, and 
lines of business using a consistent Federal Enterprise Architecture style and process can 
provide a range of benefits. This is the only practical way cross-agency information 
sharing and processing can be accomplished. It provides a consistent basis for 
comparison of investment decisions by the department and agency business leaders and 
for use by the 0MB and Congressional oversight organizations. It can provide a 
consistent method to make business oriented trade-offs and determine the expected and 
actual outcomes and performance changes based on changes in legislation, process, 
organizational structure, and the delivery of services to citizens, government, employees, 
and to other government agencies including state and local government. 

Enterprise Architecture provides the information needed to incrementally or 
dramatically modernize and transform government based on the facts of how the services 
are delivered today and how they can be delivered based on changes in the business 
process, changes in the roles, responsibilities of people, and of course the focused use of 
technology. The set of Federal Enterprise Architecture activities along with those of 
states, local government and non-government organizations can create a blueprint for 
defining the transformation steps to deliver of more efficient and effective government 
services. There are many opportunities for improvement but the active use of an 
Enterprise Architecture as the implementation plarming tool can help make “investment” 
and action decisions on where to put not only the IT dollars but more importantly where 
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to spend the “time and effort” of the government staff and the leadership based on those 
areas with the highest potential benefit and return on investment. 

One of the benefits of Enterprise Architecture is to establish a governance decision- 
making framework that typically identifies re-usable business and technical patterns such 
as shared solutions and components, interoperable data management, and data sharing 
without having to start from scratch every time. 

FEA Provides Transformational Opportunities 

As is known from private sector experience, substantial use of an EA can and, 
especially the first time used, will lead to major transformation of an organization, its 
operations and its results. While IT enables the mechanism for implementing such a 
transformation, as with most human enterprises, it is the change process for the people 
involved that is the most critical effort. For this most important reason, the lAC EA SIG 
focused its first efforts, correctly positioning the Business Reference Model (BRM) as the 
central driver for change within the organization, with the Performance Reference Model 
(PRM) as the appropriate measuring stick. 

However, there is no easy silver bullet that enables an organization to painlessly 
create and adopt an EA within the context of FEA. The creative involvement of affected 
stakeholders early in the process-so that both high-level executives and the employees at 
all levels have input and the feeling of ownership of the implementation of the EA-is 
essential for success in transforming an organization. Industry has learned many hard 
lessons, often more than once, in creating and implementing EA. Industry fully supports 
the FEA approach and through the lAC EA SIG, we are prepared to provide a means for 
the federal government to capitalize on these best practices as much as possible. 

Status of the FEA Initiatives: Good Progress, But A Long Way To Go 

Even with the Clinger-Cohen Act mandate, developing the framework for the diverse 
range of Federal entities to each define and implement their EA has been a significant 
challenge. We believe that the establishment of the FEA PMO and the development of 
the interlinked reference models are very positive and steps in the right direction. These 
reference models have the potential to form the basis for a common framework to 
improve IT investment management and enterprise- wide integration of business lines 
across agencies. OMB has led this effort very thoughtfully. They involved the 
stakeholders as the reference models are being developed and have gone through 
extensive discussion and revisions before they are published. 
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Even though initially, the need for FEA framework grew out of the realization that 
the eGov initiatives would benefit from some standardization in terms of approach, 
process and components; it allowed for significant progress in the quality of FY 2005 
agency budget preparation and the subsequent OMB budget analysis. 

The FEA initiative enabled the government to identify opportunities for improvement 
through business process integration with the five predominantly administrative/back- 
office Line of Business (LoB) such as Human Resource Management, Financial 
Management, Grants Management, Case Management and Federal Health. The General 
Services Administration (GSA) Office of Government wide Policy (OOP) is currently 
seeking industry input for some of these LoBs. This provides for an opportunity to have 
a common architecture approach for these LoBs in time to have a major impact on the 
FY06 budget recommendation to Congress by the Executive Branch. However, this 
integration effort will take a number of years to be implemented unless strong executive 
leadership, clear governance, and positive incentives are provided for agencies to 
collaborate. 

Various departments and agencies are making good progress in maturing and aligning 
their EA in the context of the FEA. EA products are being used effectively by several 
CIOs as a decision-making framework in their capital planning, portfolio management, 
policy compliance, and IT governance. There is evidence of tangible results being 
produced by EA efforts at agencies such as the US Patent and Trademark Office 
(USPTO), the Executive Office of the President (EOP), the Department of Housing and 
Urban Development (HUD), the US Environmental Protection Agency (EPA), the US 
Agency for International Development (USAID), and the Department of Veterans Affairs 
(VA). We are monitoring and supporting, where appropriate, the continued progress 
being made on some major transformation initiatives such as the Department of 
Homeland Security (DHS) EA and the Department of Defense (DoD) Business 
Enterprise Architecture (BEA). 

We would like to applaud the efforts of the OMB, GAO and the CIO Council in 
reaching out to industry in a real partnership mode not only to communicate their vision 
and plans, but also to seek ideas, input and expertise from us. We appreciate the 
leadership demonstrated by Mr. Mark Forman, Ms. Karen Evans, Mr. Bob Haycock, Mr. 
John Gilligan, Mr. Randy Hite, Ms. Kim Nelson, Mr. Dan Mathews, Mr. Marty Wagner 
and other executives for making this one of their top priorities. 
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We are very encouraged by the approach taken by GAO with their common EA 
Maturity Model Framework (EAMMF) to measure the progress of agency EA efforts in a 
very consistent and quantitative fashion. As illustrated by the recent survey, agencies 
have a long way to go to achieve the goals of EA; however we recognize that the agency 
EA efforts are maturing steadily. This improvement probably did not translate to an 
increased overall GAO EAMMF score as the current evaluation mechanism counts all or 
nothing rating for each factor and the progress at sub-factor level is not completely 
transparent. 

Major Challenges Lie Ahead 

We believe there are major challenges and obstacles that exist to be able to fully 
realize the intended benefits of FEA, especially for cross-agency collaboration and 
information sharing. Some of the major challenges that we see are: 

• EA efforts must be adopted as the main enterprise transformation mechanism by the 
mission, program and business line owners. The EA context, direction, 
development and the underlying details must be clearly driven by each owner. 
Otherwise, the value of EA will continue to be perceived as a technical exercise for 
CIOs to manage their IT infrastructure. This is a significant challenge that must be 
overcome if the agency business strategies and goals are to drive the aligtunent of 
IT capabilities and initiatives. 

• Lack of sufficient positive incentives for Federal Departments and Agencies to 
collaborate and develop common business process integration and secure 
information sharing are a cause for concern. This must be addressed quickly to 
enable a win-win scenario with the FEA and the Line of Business integration 
activities. 

• While progress has been made in integrating and improving business processes and 
the underlying systems for the administrative and back office functions, there is not 
a major thrust on the core mission functions and this could limit the return on 
investments in architecture efforts. 

• Lack of sufficient emphasis in overcoming cultural, organizational, leadership, 
transformational, and change management issues could limit progress. 
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• Lack of sufficient funding, key resources, and skills to lead and implement this 
effort across the Federal enterprise could slow the momentum gained so far and 
derail future progress. 

• Security has not been tightly integrated into the EA efforts and will be a major 
obstacle for federal agencies to collaborate and share information securely while 
maintaining an appropriate level of privacy. 

Critical Success Factors 

There are several critical success factors for FEA to fully realize its potential benefits. 

We have highlighted some important factors below: 

• Timely completion and avaiiability of the Data and Information Reference 
Model (DRM) is very important. The ability of the Federal Agencies to 
understand and map to each other’s data is a major factor in achieving the cross 
agency collaboration and information sharing. Data sharing has been difficult to 
achieve even in fully integrated private organizations. This must be given the 
highest priority within the FEA initiative in the short term, 

• Development and implementation of the “baked-in” Enterprise Security 
Architecture (ESA) aligned with FEA is paramount to the success of the 
initiative. The basic essence of ESA must be to ensure privacy while allowing for 
secure information sharing across the boundaries of the government, 

• Continued maturity and commitment to leverage FEA (by 0MB) and EA (by 
the Federal Agencies) as a management tool for budgeting and performance 

management is very important. 

• Adoption of open standards that enable the consistent expression of EA 
artifacts so that they can be inter-operable and re-used is very important to the 
future viability of EA. Some of these important standards are Meta Object Facility 
(MOF), Business Process Modeling Notation (BPMN) and Unified Modeling 
Language (UML) and the adoption of these into EA tools will accelerate the cross- 
agency collaboration. 

• FEA must be relevant and capable of adapting to emerging and future 
architecture concepts so that industry innovation is continually leveraged to 
improve government services. 

8 



106 


• A systematic way to achieve cross agency collaboration and information sharing 
could be through intra-department (agency) transformation initiatives that form the 
basis for proof points and lessons learned in a smaller scale. Continued funding 
and support for these pilot initiatives could be a key factor in validating the 
emerging FEA models. 

• More pro-active communication, detailed guidance documentation, exchanges 
and documented examples will be critical to implement the architectures 
successfully. 

• The legislative branch has a key role to play in advancing this initiative as well. 

We appreciate the pro-active and continual involvement demonstrated by the 
Government Reform Committee. We believe that articulation of legislative 
priorities and appropriation activities in the context of FEA would be very useful in 
advancing the maturity of Federal IT initiatives. 

• Last but not least, industry has a major role to play in this as a government partner. 

We strongly encourage that industry best practices, expertise and capabilities 
continue to be leveraged. 

Conclusion and Recommendations 

Mr. Chairman, lAC is very supportive of the FEA initiative as a major priority and 
agrees with its general direction. We acknowledge the significant progress made by 
OMB and many of the federal agencies. 

As we gauge the progress of this initiative by the two main subjects of this hearing, 
we conclude that: 

• High marks should be given for progress on “A Blueprint for Improved Federal IT 
Investment Management” aspect of the FEA initiative. 

• Major hurdles exist for the “Cross-Agency Collaboration and Information Sharing” 
aspect of the FEA initiative; however these hurdles can be overcome with 
commitment and leadership in stewarding collaborative efforts across agencies. 

We applaud your efforts in keeping Enterprise Architecture initiatives as a priority 
and we believe that significant challenges must be overcome to stay the course. 
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We appreciate the continued partnership between the government and industry and 
believe that this model will enable the government to continue to leverage industry best 

i 

practices, which will form the basis for future success. 

Thank you for the opportunity to appear before you today and I will be very happy to 
answer your questions. 
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EXHIBIT A 

SUMMARY OF lAC EA SIG WHITE PAPERS 

www.actgov.org 

1 . Business Integration Driven by Business Lines 

The first part of this paper discusses the needs for data modeling and how, with federation and 
modeling along business lines, the information and data models can evolve and be examined from a 
business centric point of view. This is not done from a purely technical perspective but rather from the 
perspective of the virtual “information communities” that share the common business goals within the 
lines of business that exist across various government agency boundaries. The process of gathering 
information into these communities is referred to as the “Federated Data Model.” and is based on open 
standards such as Unified Modeling Language (UML), Meta Object Facility (MOF) and extensible 
Markup Language (XML), 

2. Advancing Enterprise Architecture Maturity 

This paper describes key lessons learned from successful Enterprise Architecture programs and the 
steps they have taken to achieve their success. Specifically, the report: ( 1 ) identifies successful 
Enterprise Architecture practices, and (2) provides recommendations for cross-agency documentation, 
evolution and where appropriate, sharing of successful practices.This paper presents a number of 
practices that have been successful in advancing federal government organizations through the 
Enterprise Architecture process as presented in the CIO Council Practical Guide to Federal 
Architecture. The practices, processes, and product artifacts presented/referenced in this white paper 
are intended to provide insights gained by lAC Enterprise Architecture practitioners, and to serve as a 
mechanism for strengthening EA efforts throughout government. 

3. Business Line Architecture & Integration: 

This paper presents an overview of a Business Line oriented Solution approach with both an overall 
process and top-level reference model. The process defined uses a community based funding strategy 
and multiple levels of involvement, from the executive team to business line leaders and technical 
leaders. The approach integrates concepts and approaches from many disciplines such as enterprise 
architecture, business process management, supply-chain management, cooperative information 
systems, federated resource and data management, component-based development, declarative and 
template development, and model-based architecture and integration. The paper proposes a model- 
driven architecture made up of a combination of commercial products and “open standards” elements 
based on both open source communities and academic research initiatives that are integrated into 
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concepts such as Business Line Development Environment, Business Line Hub and the Business 
Partner Gateways. 

4. Interoperability Strategy Concepts, Challenges, and Recommendations 

The purpose of this paper is to provide some background on the issues underlying the interoperability 
challenges, to shed some light on potential approaches to dealing with the problem, and to offer some 
specific recommendations, based on industry experience, that government at all levels can implement 
to rapidly address this challenge. The Industry Advisory Council (lAC) brings an industry perspective 
to the issues facing government and offers solutions that have succeeded in commercial settings that 
may be useful in addressing the issues facing government. These recommendations are “No Regret” 
proactive actions that our government should take to move forward. This paper represents a starting 
point, a basis for initiating a dialog on how to address the issues of interoperability and information 
sharing. Concepts and Context at its most fundamental level, the concept of interoperability is simply 
about making things work together. This can be accomplished in a number ways and this paper 
discusses various options and approaches. 

5. Succeeding with Component-Based Architecture in e-Government 

Industry’s shift to Component-Based Architectures (CBA), a new Enterprise Architecture (EA) process 
for delivering applications, has fueled a tremendous amount of interest in the IT community over the 
past few years. With the search for the silver bullet that solves the continuing problems of integrating 
enterprise solutions as fervent as ever, IT organizations everywhere have jumped on the CBA 
bandwagon in hopes that it might finally ease the IT planning burden. As one might guess, it is not 
that simple. The purpose of this white paper is to provide a context for the rise of CBA, sort through 
the major issues, and provide guidance to the government business and technical managers so that 
sound business decisions can be made with respect to this key technology approach. 

This paper outlines the challenges and enablers of CBA, and provides some guidance on implementing 
CBA in government organizations. These issues are discussed at a high level this paper and several 
recommendations are provided for government consideration. 
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EXHIBIT B 

INDUSTRY ADVISORY COUNCIL 
ENTERPRISE ARCHITECTURE SHARED INTEREST GROUP 


Chair : 

Venkatapthi Puwada (PV), 

Unisys 

Vice Chair : 

Dan Twomey, Altarum 

Vice Chair : 

John Dodd, CSC 

Government Liaison Chair : 
Davis Roberts, Unisys 

Intelligence Community 
Liaison Chair : 

John Pryzsucha, BAH 


Allied Technology Group 
Aitamm 

AT&T Government Markete 
BearingPoint 
Binary Consulting 
Blueprint Technologies Inc. 
Booz-A!len & Hamilton, Inc. 
C. H. Viator & Associates 
CACI, Inc. 

CGI-AMS 

COMPUBAHN, Inc. 
Computer Associates 
International, Inc. 

Computer Sciences 
Corporation 

Data Networks Cotporation 
e-Associates LLC 
EDS Federal 
Emergent OnLine 
Everware 

Exeter Government Services 
EzGov, Inc. 

Flashline Inc. 

Futrend 
Gartner Inc. 

Hewlett-Packard 


Leadership 

Governance Subcommittee 
Chairs : 

Earl Pedersen, SAIC 
Michael Tiemann, AT&T 

Components Subcommittee 
Chair : 

Ed Robinson, Binary 
Consulting 

Components Subcommittee 
Chair : 

Vicki Thompson, Unisys 

Emerging Technologies 
Subcommittee Chair : 

Joe Brophy, ObjectBuildere 

Membership 

High Performance 
Technologies 
IBM Corporation 
iCF Consulting 
ICHnei.org 
Intel 

Johnston McLamb Case 
Solutions, Inc. 

Knowledge Consulting 
Group 

KSJ and Associates Inc. 

LEADS Corporation 
Managed Objects 
Management Systems 
Designers, Inc. 

MCI WorldCom 

META Group 

Microsoft Corporation 

NCI Information Systems 

Open Systems and Data Solutions 

OPTIMOS Inc. 

ORACLE Corporation 
Pearson Government Solutions 
Price Systems 
Price Waterhouse Coopers 
ProSight 


Emerging Technologies 
Subcommittee Chair : 
Kristina Glanders, LMI 

Secretary : 

Kay Cederoth, CA 

Program Chair : 

Tony Kitzmiiler, Ciber 
Federal 

Program & Membership 
Chair : 

Jeanne O'Kelley, Blueprint 
Technologies 


• PureEdge Solutions 

• QSS Group Inc. 

• RGIl Technologies, Inc. 

• SAIC 

• Sapient 

• SAS Institute 

• SeeBeyond Technology 
Corporation 

• Serendipity Consulting 

• SI International, Inc. 

• SiloSmashers 

• SRA International 

• Sun Microsystems Federal 

• Sytel Inc. 

• Tasman Networks 

• Titan 

• Troux Technologies 

• Unisys U.S. Federal 
Government Group 

• Vencal Global 
Solutions 

• Vignette Public 
Sector & Education 

• Webworld Studios 

• Xaware Inc 
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Mr. Putnam. Thank you very much. 

Our next witness is Norman Lorentz. Mr. Lorentz joined 
DigitalNet as senior vice president in September 2003. Prior to 
that, Mr. Lorentz served as the first Chief Technology Officer for 
the Federal Government at the Office of Management and Budget, 
where he was also the Acting Administrator for E-Government and 
Information Technology. While at 0MB, Mr. Lorentz spearheaded 
the White House mission to overhaul the Federal Government in- 
formation technology infrastructure and its processes. In driving 
this initiative, he directed the development of the Federal Enter- 
prise Architecture. In addition, during his tenure with 0MB, Mr. 
Lorentz was a member of the Chief Information Officer Council’s 
Executive Committee and the recipient of numerous government 
and industry awards for his leadership and innovation. 

You are a frequent guest of this subcommittee. We are delighted 
to have you back, and you are recognized for 5 minutes. 

Mr. Lorentz. It is nice to be invited back, and also members of 
the subcommittee. I am here today to talk about the progress that 
has been made on the implementation and operationalization of the 
FEA in 0MB and the Federal agencies. 

In my role as CTO of the Federal Government and 0MB, I di- 
rected the development of the FEA. I believed then that the FEA 
provided a tremendous amount of promise in becoming the struc- 
ture for governance for the effective development and management 
of information technology and other asset classes in the Federal 
Government, and I continue to advocate that today. 

I would like to talk a bit about the current situation, what the 
value of the FEA is to the agency and citizens, the impact on the 
business plan process, the continuing challenges, and then, finally, 
success factors. 

The FEA models are just about finished. The data reference 
model and the security profile that has already been discussed are 
about to be completed, and this framework will provide significant 
progress. The FEA really consists of two components: the frame- 
work outline in the FEA models, as well as the EAs that are in the 
agencies themselves. Without the connection between the FEA and 
the EAs, there is not a solid construct within which to make invest- 
ment decisions. 

In the past couple of years, and we have already discussed in 
quite detail, the GAO and 0MB have provided assessment models. 
What I would say about assessment models is that they are nec- 
essary, but they are not sufficient. What is sufficient is the meas- 
urement of citizen and mission-centered results. These assessment 
models are used to describe a weigh station, not the end result. 
And, finally, 0MB is using the FEA to identify high priority Lines 
of Business and consolidation in the context of those Lines of Busi- 
ness. 

The value to the citizen is that the FEA provides visibility into 
the agencies’ business and solidifies future business plans. It helps 
reduce the cost of current business processes by eliminating 
redundancies and improving the efficiency of IT investment. The 
outcome for the citizen is high-quality cost-efficient government 
services. 
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From an investment standpoint, the FEA supports the establish- 
ment of a portfolio approach to prioritize IT investments. Without 
the FEA, the Federal Government would not be able to prioritize 
in a collaborative manner in these investments addressing the 
highest priority for the citizen. From a governance standpoint, the 
FEA provides a holistic point of view; it gives both a business per- 
spective in terms of the performance and business reference model, 
which is the “what” for the improvement, and then it also provides 
the more technically oriented reference models, which describe the 
“how.” And from a technology standpoint, FEA provides a coordi- 
nated approach to reporting between 0MB and the Chief Informa- 
tion Officer’s Council is making significant progress in maturing 
the reference models. 

The impact of the FEA on the business case process in 0MB. Al- 
though the agencies have been making progress in the business 
cases, last year, the first year, the 0MB issued guidance in A-11 
that included specifics on the FEA. Doing so was a significant step. 
The agencies should provide similar guidance for consolidation op- 
portunities in the context of the EAs. 

The continuing challenges. Some agencies are struggling to im- 
plement the FEA. As 0MB provides additional support in the ref- 
erence model areas, this should be accelerated; in building and ma- 
turing EAs and gaining participation and ownership of the busi- 
ness areas. This is not a technology problem, this has been rein- 
forced many times. This is a business problem, so it requires busi- 
ness leadership in the agencies; deputy secretaries, chief financial 
officers, as well as the chief information officer. There is limited 
up-front visibility in the detail of other agencies’ EAs, and so the 
FEA provides the construct up front to be able to do those consoli- 
dation analyses. The target EAs for the agencies are limited in 
their forecast and scope. In other words, they cannot see very far 
into the horizon. And some agencies have separated EA and capital 
planning, and that is not sufficient. 

Critical success factors. As an integrated governance model, a 
marriage between the business owner, the chief financial officer, 
and the chief information officer in making the business decisions. 

To reinforce what my partners here have already said in terms 
of the chief architect position, it is necessary that we provide some- 
one to that position who has both business and technology exper- 
tise. And, also, that 0MB architect position is necessary, but not 
sufficient. There is further analysis resources that are required at 
0MB level in order to be able to do the cross-organizational analy- 
sis for transformation. 

In conclusion, I have recognized significant progress, and we 
have heard that said here. There has been much that has been ac- 
complished, but there is still work to be done. And, finally, in a fu- 
turistic scenario, right now the Federal Enterprise Architecture is 
being viewed to look at the IT asset class. But this business-ori- 
ented Federal Enterprise Architecture can also be used for the 
other asset classes: human capital and fixed assets. 

Thank you for the opportunity to be here today, and I would look 
forward to your questions. 

[The prepared statement of Mr. Lorentz follows:] 
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STATEMENT OF 
MR. NORMAN E. LORENTZ 
SENIOR VICE PRESIDENT 
OF INTERGOVERNMENTAL SOLUTIONS FOR 
DIGIT ALNET GOVERNMENT SOLUTIONS 
BEFORE THE 

COMMITTEE ON GOVERNMENT REFORM SUBCOMMITTEE ON 
TECHNOLOGY, INFORMATION POLICY, INTERGOVERNMENTAL 
RELATIONS, AND THE CENSUS U.S. HOUSE OF REPRESENTATIVES 

May 19, 2004 

Good afternoon, Mr. Chairman, Ranking Member Clay, and Members of the 
Subcommittee. Thank you for inviting me here to speak on the progress being made by 
the Office of Management and Budget (OMB) and the Federal Agencies in the 
development and “operationalization” of the Federal Enterprise Architecture (FEA). 

Prior to joining DigitalNet, I was privileged to serve as the Acting Administrator 
of Information Technology (IT) and e-Gov as well as the Chief Technology Officer 
(CTO) for the Federal Government in OMB. In my role as CTO, I directed the 
development of the FEA. I believed then that the FEA had tremendous promise to 
become the structure for governance of the effective development and management of 
Information Technology in the Federal Government, and I continue to be an advocate for 
the FEA today. 

My comments will focus on the current status of the FEA and the progress made 

to date: 

• The value of the FEA to Agencies, and, more importantly, citizens 

• The impact of the FEA on the business case process at OMB 

• Continuing challenges faced by the Agencies and Departments in integrating their 
enterprise architectures and; 

• FEA success factors. 

FEA Progress and Status 

The FEA Models are in the final stages of completion, with only the formal 
releases of the Data Reference Model (DRM) and the Security Profile remaining. 
Although new versions will be released over time, the initial framework will be complete, 
and 1 believe this is significant progress. 

The FEA really consists of two components: the framework outlined in the FEA 
Models, and the agency Enterprise Architectures (EAs) that are linked to that framework. 
The first of these components will be ready with the completion of the FEA Models. Both 
components must be in place to have an actionable FEA - one that becomes a solid 
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construct upon which to make investment decisions. In our support of Government EA 
practices, we are finding that Agencies are making progress developing their EAs, but 
they have significant work ahead to mature and “operationalize” them. 

One strong positive note is that the General Accounting Office (GAO) and OMB 
direction is consistent. In the past couple of years, both GAO and OMB have released 
complementary maturity assessment guidance related to the FEA. This is highly 
beneficial to the Agencies who are trying to do the right thing. Although the assessments 
are necessary to the FEA maturation process, they alone are not sufficient to measure 
success. The key FEA success criteria are citizen- and mission-centered results. 

Finally, OMB is using the FEA to identify high-priority lines of business for 
detailed analysis and architecting Government-wide solutions (e.g., the line of business 
consolidation analysis). 

Value of the FEA to Agencies and the Citizens 

At a practical level, the FEA provides visibility into the details of an Agency’s 
business and solidifies future business plans. Having this visibility helps the Agency 
make better business decisions, close performance gaps, and prioritize future investments 
aimed at improving mission performance. It also helps them reduce the cost of current 
business processes by eliminating redundancies and improving the efficiency of the IT 
inffastracture. The outcome is that the citizen receives high-quality, cost-efficient 
Government services in the following maimer: 

• From an investment standpoint, the FEA supports establishment of a portfolio 
approach to categorize and prioritize annual IT budget requests and review IT 
program performance. The FEA has done more than any other Federal initiative to 
help Agencies begin to reduce the duplication of IT resources. With total investments 
in IT resources topping $60B in FY 2005, and with many Agencies becoming highly 
dependent on IT resources to accomplish their missions, the FEA represents a 
foundational element of IT portfolio management. Without the FEA, the Federal 
Government will not be able to prioritize investments in a collaborative manner such 
that these investments address the highest priority service needs of the citizen. 

• From a governance standpoint, the FEA provides the first holistic view of IT assets 
across the Federal Government in a way that maps these assets to lines of business 
and performance outcomes. This is essential to identifying where gaps in Federal 
services exist, at a level beyond that which individual Agencies can see. In terms of 
the Reference Models, the Performance Reference Model and Business Reference 
Model are the governance areas of the FEA and help agencies decide which business 
lines and processes require investments. The Technical Reference Model, Service 
Component Reference Model, and the Data Reference Model help Agencies decide 
how to select and manage investments to close performance gaps and improve 
effectiveness and efficiencies of the programs. Additionally, the FEA-related 
information that annual OMB submissions now provide on IT programs gives 
unprecedented levels of detail about how IT is being used in support of mission 
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functions. 0MB is therefore in a better position to accomplish its oversight charter 
and provide IT leadership for the Administration. 

• From a technology standpoint, the FEA provides a coordinated approach to EA 
reporting and analysis by standardizing and unifying approaches between Agencies. 
The National Institutes for Standards and Technology (NIST) sets the standards that 
reside in the Agency’s standards profiles. Also, the partnership between 0MB and the 
Chief Information Officer (CIO) Council is making rapid progress on maturing these 
Reference Models and their use in the planning and management of investments. 

With further development and maturity, the FEA can provide a standard approach to 
IT solutions planning. Further, the e-Govemment initiatives (that are intrinsically tied 
to the FEA) are already providing solutions to citizen and industry service 
requirements on an accelerated basis. 

The FEA also has helped to awaken the Federal sector to the increasingly 
sophisticated and complex service requirements from citizens, industry, and other 
Government Agencies. As more services are electronically provided, architectures to 
enable those services must reach well beyond current approaches, and the FEA is 
positioned to do that. Without the FEA, there is a real possibility that citizen/industry 
service expectations would not have been met with effective cross-government solutions 
for a number of years. This has been avoided, in large part, because of the FEA and its 
role in supporting all elements of the President’s Management Agenda (PMA), but most 
significantly. Strategy Area Number 4 — expanding E-Govemment. 

The Impact of the FEA to the Business Case Process at OMB 

Although Agencies have been making progress in improving their business cases 
and individual agency EAs, last year was the first year that OMB issued budget guidance 
in Circular A-U that included specifics on the FEA. Doing so was a significant step 
forward in furthering OMB’s ability to analyze the Federal Government’s IT investments. 

There is a great deal of business case work that is EA work, and vice-versa. FEA- 
related questions appear in both Part I and Part II of the OMB Exhibit 300 budget request 
document, which is central to the current approach to Federal capital planning and the 
business case process. The FY 2005 OMB Circular A-1 1 required a great deal more 
information about the intersections of EA and Capital Planning Investment Control 
(CPIC). A mature and actionable EA provides a great deal of input into the overall 
business cases within an Agency. There is a very structured crosswalk between elements 
of the FEA and the business cases. The Business Reference Model information provides 
data for the justification and description areas of the business cases, while the 
Performance Reference Model includes specific performance information that is included 
in the business cases in the areas of the performance table and the project and funding 
plan. Further, the Technical Reference Model and Service Component Reference Model 
includes information for use in the Alternatives Analysis, Risk Management, and IT 
Security sections of the business case. 


The FEA information provides the construct for a robust technology analysis, 
which complements the robust financial analysis performed as part of the budget process. 
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This balance of financial and technical information is what is needed to make informed 
IT investment decisions, and the FEA has been structured to provide useful information 
for this process. 

Continuing Challenges 

Although significant progress has been made, both 0MB and the Agencies face 
continuing challenges as they mature the FEA: 

• Some Agencies struggle with how to implement the FEA. As 0MB continues its effort 
to mature the FEA models and strengthens the documentation for FEA 
implementation methodology. Agencies will also accelerate maturity and 
implementation, and this problem will be resolved. 

• In building and maturing EAs, gaming participation and ownership by the business 
areas can be tough. The business area leaders are the only ones who can articulate the 
details related to their business and define what success looks like. Without this 
foundation within the business and performance layers of the architecture, its use is 
limited. 

• There is limited up-front visibility into the details of other Agencies ’ EAs, thereby 
restricting early partnerships and collaboration. When Agencies have investment 
needs, they refer to the FEA Models to identify other Agencies supporting the same 
lines of business. Flowever, without details into other Agencies’ EAs, beneficial 
collaboration opportunities are not always apparent. 

• Agency target EAs are often limited. Because the traditional IT strategic planning 
processes look 3 to 5 years into the future, most target EAs lack long-term vision. 
Leading Agencies are beginning to use techniques such as scenario planning as a 
thought-stimulating technique to envision how their mission services can be delivered 
in the future. 

• Some Agencies still have independent EA and capital planning organizations with 
disconnected governance processes. Because they are not integrated, the full benefit 
of the FEA is not achieved and may not be reflected in their investment decisions. 

• The CIO 's influence on the budget is dependent on the strength of the Agency 
integrated governance process and the relationships between the CIO, Chief 
Financial Officer (CFO), and business leaders. This is also true in the private sector, 
with technology being a key business process enabler. The value of the FEA is also 
dependent on the Agency’s recognition of the CIO as having a leadership role 
regarding the IT budget. 

FEA Success Factors 

An Integrated Governance Model. Laws, new policies, new business needs, and 
emerging technology drive business decisions. The FEA provides the foundational 
constmct to operationalize those business decisions, reducing duplication and 
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redundancy, and improving business efficiency and mission performance. Even when the 
FEA is technically complete, if not integrated with strategic planning, CPIC, security, 
human capital, and project management, it can not be leveraged at the right time by the 
right people to make the right investment decisions. 

The OMB Chief Architect. Unless the OMB has a knowledgeable EA leader, the 
overall Government-wide momentum gained by the EA Programs over the past several 
years will be adversely impacted. The individual selected must be knowledgeable of both 
business and technology, and the position must be filled quickly. 

Chief Information Officers. CIOs are central to the FEA success and should 
have the status and authority to use the FEA to influence IT investment decisions. 

Budget Guidance. OMB now includes FEA guidance as part of the “Spring 
Guidance” letters issued during the budget process. The same practice should be mirrored 
within the Agencies. This would ensure that the FEA gains high-level attention as 
Agencies prepare their budget submissions. 

Conclusion 

I recognize the significant progress that has been made on development and 
implementation of the FEA framework. It is commendable, and it provides a solid 
foundation for the Agencies to integrate their individual EAs, resulting in an actionable 
FEA. 


While much has been accomplished, there is still work to be done. Critical actions 
are needed to move the FEA forward. For example, 1 believe hiring a Chief Architect at 
OMB tops the list. Furthering the line of business consolidation analysis is also very 
important. 

Finally, I’d like to close with a futuristic scenario. Imagine an FEA with not only 
IT assets linked to lines of business, but also human capital and other fixed assets, such as 
facilities, equipment, and vehicles. This expansion would revolutionize the budget 
process! 
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Mr. Putnam. Thank you very much. 

Our final witness on this panel is Dr. Raymond Wells. Dr. Wells 
is the chief technology officer for IBM Federal and vice president, 
Strategic Transformations for the IBM Software Group’s Applica- 
tion Integration & Middleware Division. In addition, he is on as- 
signment to one of the U.S. Government’s classified agencies. Prior 
to accepting the CTO Federal position in October 2002, he was Di- 
rector of Strategy for 4 years. He has 35 years experience in infor- 
mation technology and has heen employed with IBM since 1993. 
Dr. Wells has served in various administrations of the State of Ala- 
bama and as the Chief Financial Officer for the State of Alabama. 
He began the process of transforming the State’s financial manage- 
ment systems. Later, as Chief Technology Officer, he completed the 
transformation, known as the Financial Resources Management 
System, the most integrated financial management system in the 
public sector at the time. 

Welcome to the subcommittee, and you are recognized for 5 min- 
utes. 

Mr. Wells. Thank you, Mr. Chairman. IBM appreciates the com- 
mittee’s invitation to speak today about the Federal Enterprise Ar- 
chitecture. Our message to the committee today is quite simple: the 
focus provided by the Federal Enterprise Architecture initiative of 
the Office of Management and Budget is sound policy. FEA is 
about leveraging technology to focus on strategic priorities. Enor- 
mous benefits will be returned to the Government and its citizens. 

Enterprise architecture is a framework or a set of interlocking 
frameworks which has as its core the organization’s mission and 
strategy. It is about the strategic management of technology re- 
sources which provides the substantiation and manifestation of effi- 
cient and effective business processes. This is paramount. Under- 
standing the key business processes is a prerequisite for 
prioritizing and guiding information technology investments. 

Perhaps no organization understands this better than IBM. Our 
own transformation has an obvious relevance to the business mod- 
ernization efforts now in progress within the Federal Government. 
IBM underwent a major financial, competitive, and cultural trans- 
formation beginning in 1995. IBM refocused itself on the customer 
in the marketplace as the measure of success and recreated the 
company as an entity that could translate technology into business 
value. 

The Federal Government finds itself in much the same situation 
as IBM 10 years ago, a vast, siloed organization with disparate in- 
formation technology systems, a multitude of data bases and appli- 
cations that didn’t work with each other, and with complex and 
often competing business processes that hindered organizational ef- 
ficiency. 

IBM’s own transformation required a fundamental reexamination 
of everything that we were doing. We consolidated and focused our 
business processes, improved our time-to-market by 75 percent, re- 
duced business applications we used to run the business from 
16,000 to 5,200, consolidated 155 data centers into 12, reduced 31 
private networks into 1, went from 128 different CIO positions to 
1; we have installed multiples of the IT capacity that we had in 
1993 at roughly one third the cost. In short, we learned to manage 
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technology strategically and discovered it was less expensive and 
vastly improved productivity. 

So enterprise architecture is about common processes and sup- 
porting systems based upon open standards which foster interoper- 
ability. Enterprise architecture also has the additional advantage 
of helping to create a unified culture within the agency. IBM’s ex- 
perience dictates one key facet for success: the key to enterprise ar- 
chitecture is sustained executive commitment and the strategic al- 
location of resources to key operational initiatives. 

At the leadership and framework level, the Federal Government 
is approaching FEA correctly; there is a program office in place to 
manage the process, a management system is available which pro- 
vides agencies the tools to assess enterprise architecture require- 
ments and develop and implement their own enterprise architec- 
tures. Empirical knowledge and effective solutions are being cap- 
tured so that the agencies can reuse and extend lessons learned, 
avoiding duplication and leveraging available resources. 

As in any major transformation effort, there are areas for im- 
provement. The examination of OMB’s scorecard, as has been re- 
peated here, shows some agencies moving more rapidly than oth- 
ers. In some instances this can be explained by the sheer complex- 
ity of the operational requirements and technologies that need to 
be mapped. What is needed is more agency leadership on enter- 
prise architecture implementation and more discipline with respect 
to strategic IT investments. We still see far too much in the way 
of tactical investment in technology. 

Consider the Department of Defense, with over $1 trillion in as- 
sets and an annual budget of roughly $400 billion and 3 million 
military and civilian employees, global missions, facilities and sup- 
pliers. DOD is obviously the world’s largest and most complex en- 
terprise. DOD’s enterprise architecture is the largest, most com- 
plex, and most pervasive enterprise architecture developed to date, 
either in the public or private sector. Historically, the Department’s 
services and agencies have used individual procedures with mul- 
tiple systems to support those procedures. This limits DOD’s ability 
to provide timely, accurate, and reliable business and financial 
management information, and creates a higher than necessary cost 
for performing the business of defense. 

IBM, along with others, has delivered to the DOD the first stages 
of an enterprise architecture that will help transform and modern- 
ize key business operations. Developing this framework has been 
and remains a massive undertaking, involving over 2,000 informa- 
tion systems and many thousands of business processes. Hundreds 
of existing policies will change, dozens of systems will be modified, 
more than 1,000 existing systems will be sunsetted, and more than 
100 new systems will be implemented. 

A key component of any agency transformation involves cultural 
change. You can’t do business the same way. Moving to a common 
agency enterprise architecture and the infrastructure it fosters will 
contribute to building agency culture. However, sustained commit- 
ment of top management officials is required for success. 

Enterprise architecture is an enabler of the transformation of 
government. Enterprise architecture provides the basis for evo- 
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lution from tactical to the strategic management of technology as- 
sets and significant transformation and operational processes. 

Mr. Chairman, thank you for the opportunity to discuss our 
views and experience with you. I look forward to answering any 
questions you may have. 

[The prepared statement of Mr. Wells follows:] 
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Mr. Chairman and Members of the Subcommittee, I am Raymond Wells, Chief 
Technology Officer, U.S. Federal Industry and Vice President of Strategic 
Transformation for IBM’s Software Group. 

IBM appreciates the committee’s invitation to talk about Federal Enterprise 
Architecture. We are pleased to submit this written testimony for the committee's 
record. 

My message to the Committee today is rather simple. The focus provided by the 
Federal Enterprise Architecture initiative of the Office of Management and 
Budget is sound policy. It helps agencies leverage their technology and their 
operational processes to focus on strategic priorities. This will be of enormous 
benefit to the government, citizens and vendors. 

Simply put, an Enterprise Architecture is a framework, or more specifically, a set 
of interlocking frameworks that must have at their core the organization’s mission 
and strategy. The framework will define the infrastructure and technological 
capabilities that the organization requires, as well as the business processes and 
data it needs to accomplish its mission. At a high level, we have a technical 
architecture and a business process or business reference architecture; and, to 
reiterate, both must strongly reflect and be aligned with the organization’s 
mission and strategy. 

An agency preparing its Enterprise Architecture should avoid considering it to be 
an academic exercise or an obstacle to be overcome in the acquisition process. 
Key business processes should guide and provide the priority for information 
technology investments. Enterprise Architecture is not about technology. Rather, 
it is about the strategic management of technology resources to provide the 
installation and manifestation of efficient and effective business processes. 
Tactical management of technology is excessively expensive; EA provides the 
framework for strategic allocation of information technology resources. 

The Office of Management and Budget’s Federal Enterprise Architecture (FEA) 
begins with a correct assumption. An Enterprise Architecture is more than 
technology or processes. It is strategic. It must be continually assessed and 
actively managed in order to align the organization’s vision and its information 
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technology investments, and to facilitate the achievement of the Agency’s 
initiatives, and, ultimately, its mission. 

Technology's primary purpose is to act as an enabler of efficient and effective 
processes. The use of information-systems technology has evolved from the 
automation of simple but repetitive tasks to the management of complex 
business and mission processes today. Most organizations can no longer 
function if automated systems are unavailable. 

No\« technology is shifting to become a key component of service delivery. 

Industry discovered during the 1990's that a paradigm shift had to occur in the 
management of information technology assets. They needed to be managed as 
a strategic asset not a collection of tactical assets. A generation of easily 
deployed technologies resulted in the proliferation of hardware and software 
assets managed by different organizational entities with various levels of 
expertise. 

The result was extraordinary inefficiency in the application of technology assets 
and a resulting inefficient cost structure. 

International Business Machines Corporation, by focusing on using technology to 
enable core business processes has reduced its cost structure significantly, 
allowing us to use that money in the pursuit of core business purposes. 

The lesson is simple; the strategic management of technology assets, aligned to 
core business processes, is far less expensive and far more productive. 

Let me elaborate further on IBM’s transformation in the utilization of technology, 
and show its obvious relevance to the business-modernization efforts in progress 
within the Federal Government. 

IBM’s Business Transformation 


IBM has undergone a major financial, competitive, and cultural transformation 
since 1993. That year, a new vision took hold within IBM that sought to refocus 
on the customer and the marketplace as the measure of success, and recreate 
the company as an integrator that could translate technology into business value. 


The need for this transformation was self-evident; In 1993, our stock price hit a 
20-year low. We posted an $8.1 billion loss. We failed to recognize fundamental 
changes in the marketplace and saw our profit margins evaporate. IBM operated 
24 separate business units, which together sold more than 5,000 hardware 
products and 20,000 software products. Efforts at cost-cutting and efficiency 
were dampened by our size and complexity of our operations. 
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IBM's transformation began with a fundamental examination of everything the 
company was doing and the processes by which the enterprise was being run. 
Cutting costs and driving common processes and systems across the entire 
global IBM organization became the key to going to market as One IBM, Among 
our efforts: 

• Internal Business Processes - By consolidating and focusing on our internal 
business processes, IBM improved our time-to-market by 75 percent. This saved 
more than $9 billion. 

• Software Applications - Prior to our transformation efforts, IBM ran more than 
16,000 unique software programs. Now that number is less than 6,000. 

• Infrastructure - Within IBM, we consolidated 1 55 data centers, 1 28 CIO 
positions, 31 private networks and hundreds of different PC configurations into; 

12 data centers worldwide; one network; four PC configurations; and one CIO. 

These were but a few of our internal accomplishments. 

As a recent IDG case study put it, “Since IBM embarked on its business 
transformation nearly a decade ago, the company has gone from a collection of 
siloed business units to an agile and integrated enterprise focused on the 
customer.” 

IBM has seen direct business results from this transformation: 

• From 1 994 through 2003, IBM’s e-business transformation efforts have 
realized $17.4 billion in cost savings from $6.4 billion in investment. 

• From 1993 to 2003, IBM reduced IT spending by 31 percent, while increasing 
our IT resources about 2.5 times (since 1996) to support new applications and 
processes, additional workload volume, enhanced functionality and acquisitions. 

• We have continued to move procurement to the Internet, now purchasing 
some 95 percent of goods and services electronically, generating more than 
$400 million in cost avoidance. 

Now we have taken our EA-enabled transformation a critical step further: 
creating the e-Business On Demand model that we believe will be the driving 
force in global business in the near future and beyond. 

An on-demand business is an enterprise whose business processes - integrated 
end-to-end across the company and with key partners, suppliers and customers - 
- can respond with agility and speed to any customer demand, market 
opportunity or external threat. An on-demand business: 

Is responsive - responding almost intuitively to dynamic, unpredictable changes 
in demand, supply, pricing labor, competitors’ moves, capital markets and the 
needs of its constituencies - customers, partners, suppliers and employees. 
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Uses variable cost structures and adapts processes flexibly. This flexibility will 
enable it to reduce risk and to do business at high levels of productivity, cost 
control, capital efficiency and financial predictability. 

Is focused on its core competencies, its differentiating tasks and assets, while 
tightly integrated strategic partners manage selected tasks - from manufacturing, 
logistics and fulfillment to HR and financial operations. 

Is resilient enough to manage changes and threats - from computer viruses, to 
earthquakes, to spikes in usage - with consistent availability and security. 

IBM believes that as governments, including the United States and its agencies, 
adopt and embrace the on-demand model, our leaders will be enabled to see 
and manage their agencies as an integrated whole, central to the transformation 
process. 

What are the Benefits of an Enterprise Architecture? 

The IBM story has obvious parallels to the federal government’s EA efforts. That 
brings us to the benefits of the Enterprise Architecture. The primary benefits of 
an Enterprise Architecture are to move toward common processes and systems, 
department-wide and cross-agency where appropriate, and to foster more 
efficient communication, collaboration, and cooperation, through shared business 
processes and information. It also has the additional advantage of helping to 
create a unified “culture” within the agency. 

A living Enterprise Architecture: 

Provides a migration path to get to the strategic infrastructure / 
capabilities 

Facilitates program planning and acquisition decision-making 

o Use and reuse of common components 

o Utilizes consistent frameworks, blueprints, process models, 
technology 

o Prevents duplicate data being created/deleted by multiple 
processes 

o Facilitates a simplified technology infrastructure 

0 Makes it easier to mix and match, and to use best of breed 
solutions 

0 Impact of changing process or technology can be evaluated 
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Improves time to program implementation 

0 Better identification and clarification of scope of project start 
0 Uses a structured approach to management and development 

o Improved communication through a common approach 
(frameworks, blueprints, processes) 

Improves resource allocation 

o Assists in preventing process or technology gaps and overlaps 

o Creates a more flexible technology infrastructure that is transparent 
to the user 

o Includes allocation of people, time, and money 

Facilitates continuous improvement 

o Technology changes and upgrades are hidden from the users 

o Able to apply any new programmatic or process scope requirement 
o Metrics and measurements are designed into the process 

Provides more flexible and robust, integrated processes and 
applications 

o Includes integration of security and privacy elements into the 
framework and processes 

Assists prevention of unnecessary organizational role development 

o Uses consistent roles and relationships 


What are the kevs to implementing a successful Architecture Management 
Process? 

Proper organization and staff must be in place, EA organizational 
alignment with the functional organizations is key. 

. ■ Clear ownership of the Enterprise Architecture at each levei, with specific 
process owners, component leaders and department and agency 
participation 

Active sponsorship and championing including visible management 
support from Senior Officials 
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Proper level of resources (people, tooling, etc.) must be obtained and 
sustained to support all priority transformation operational initiatives. 

An Architectural Management Process, such as the Federal Enterprise 
Architecture Management System (FEAMS) needs to be clearly defined 
and understood. The process must be flexible enough to adapt to 
departmental needs and changes as necessary. It must be a dynamic 
process that adds real value to the agency, not just something to be 
ticked off on the checklist. 

The organization must have effective communications and distribution of 
the process. The Enterprise Architecture must be constantly and 
consistently marketed by the staff and departmental leadership. The 
process must be built into the culture of the agency and its mission. 


What is the Federal Government Doing Right? 

I would say that at the leadership and framework level the Federal Government is 
approaching FEA in very much the right way. The Architecture has been defined 
(all 5 major elements of it), there is a program office in place within 0MB to help 
manage the process, and there is a Management System (FEAMS) now 
available that gives agencies the tools to assess their requirements and to 
develop and implement their own Enterprise Architectures. FEAMS also includes 
a repository of process solutions from other agencies that can be reused or 
extended, to avoid duplication and to better leverage available resources. 

At the OMB level, and from an outsider’s perspective, it would appear that the 
process is being well enforced, EA-related submissions are required as part of 
agency budgetary requests, whether programmatic or IT, and help to define the 
value and results expected, and how the proposed expenditures fit within the 
strategic framework. 

As part of this process, OMB has given the agencies a high-level framework, 
along with tools and guidance, to do Enterprise Architecture Assessments. 

Among other factors OMB considers are the maturity of an agency's EA, 
including the status of the agency EA development, and how capable the EA is of 
being able to guide the agency’s strategic investments. A successful EA 
implementation will give the agency an extremely powerful mechanism to enable 
successful transformation in achieving the agency’s mission. 

The other major factor: how is the agency EA being integrated with the broader 
FEA model. Consistency with the broader FEA model is important for broader 
collaboration and information sharing, as well as for cross-agency solutions. 

The annual Exhibit 300 performance review requirement establishes metrics for 
how an agency is progressing in its strategic implementations, and what value 
has been created by its actions, including those in developing and implementing 
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its EA. This creates quantitative assessments that demonstrate both value and 
good management. Agency EA progress is further monitored through the 
quarterly scorecard reviews. 

Is there room for Federal Government improvement in implementing the 
FEA? 


The opportunity for Enterprise Architecture improvement is not one that is limited 
to the Federal Government, but since that is the question asked, I’ll answer, yes, 
there is room for improvement. 

I believe the question is not, is the right framework and management guidance in 
place through the efforts of, among others. 0MB, the Federal CIO Council, as 
well as legislative guidance and oversight by the Congress. I believe that 
framework and guidance is good. What needs to be done now is to assure that 
departmental and agency leadership have bought into the EA process and are 
driving their organizations accordingly. 

What we see, if we examine the 0MB scorecards, is that some agencies are 
moving much more rapidly than others in developing and implementing their EAs. 
In some instances, this can be explained, not by a lack of interest or leadership, 
or by a lack of actual hard work, but by the complexity of the technological 
capabilities and operational requirements that need to be mapped. As an 
example, one only needs to look at the very good work the Department of 
Homeland Security is doing to determine how great is the effort needed to 
identify these requirements and to create an architecture to integrate the 
technological infrastructure and processes of the 22 component agencies of that 
department. 


The Department of Defense Example 

Perhaps no better example exists of the challenges facing the Federal 
Government than that of the U.S. Department of Defense. With over $1 trillion in 
assets, an annual budget of $378 billion and 3 million military and civilian 
employees, as well as global missions, facilities and suppliers, DoD may be the 
world’s largest and most diversified enterprise. Therefore, the DoD's enterprise 
architecture is the largest, most complex and most pervasive enterprise 
architecture developed to date, either in the public or private sectors. 

Historically, the Department’s Services and agencies have used many individual 
procedures to conduct their work, as well as a multitude of systems to support 
those procedures. Most of these business processes have focused primarily on 
the Services’ and agencies’ own operations. This has placed limits on DoD’s 
ability to provide timely, accurate, and reliable business and financial- 
management information, and to share information. This, in turn, has created 
higher-than-necessary costs for performing the business of defense. 
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In April 2002, as part of its Business Management Modernization Program 
(BMMP) the U.S. Department of Defense (DoD) contracted with IBM, working 
with other subcontractors, to develop a framework to transform and modernize 
the way DoD conducts all of its business operations, including strategic planning 
and budgeting, financial management and accounting, installations and 
environment, human resources, logistics and procurement. This framework has 
four main keystones: 1 ) A “to-be” DoD Business Enterprise Architecture; 2) A 
capabilities-driven Transition Plan; 3) Portfolio management and system 
assessment; and 4) A transformation governance and champion organization. 
Developing this framework has been and remains a massive undertaking 
involving over 2,000 information systems and many thousands more business 
processes. 

I want to focus on the Business Enterprise Architecture, or BEA, which has been 
created from the many capabilities and thousands of business processes I 
mentioned. The BEA model represents the enterprise end-to-end operational 
processes and activities, information exchanges, and the corresponding systems 
and technology requirements, that is, it identifies the “to be” capabilities. The 
model is executable because it provides a clear template for programs, solutions, 
and other key operational outputs that enable the end-to-end missions of DoD 
Services and Agencies. The operational results of these BEA-compiiant 
programs and solutions will collectively achieve DoD’s Enterprise strategic goals. 
The BEA model is also executable because it facilitates the development of a 
Transition Plan based on BEA-based strategic capability needs. Finally, the BEA 
model is executable because an acquisition and management system can be put 
in place to oversee the Transition Plan. 

To give you an indication of the scope and complexity of the effort, it took a year 
to develop the initial version of the Activity Model of the DoD Business Enterprise 
Architecture, which was delivered, on schedule, on May 1 , 2003. This Activity 
Model is part of the “to be” view of the architecture that will drive DoD’s business 
operations in the future. The Activity Model depicts more than 740 activities, 
2,589 information exchanges, 9,946 definitions, 76 data stores, 1 ,081 business 
rules, and 4,020 business and financial requirements. 

Culture change is a key component of BMMP. Hundreds of existing policies will 
change. Dozens of existing systems will be modified. More than 1 ,000 existing 
systems will be phased out and more than 100 new systems will be 
implemented. 

The Business Management Modernization Program will enable DoD to provide 
greatly improved support for the warfighter. The program will aid DoD in a vast 
array of tasks, from the mundane, such as issuing supplies on time and with 
reduced paperwork - to those critical to our country’s defense, such as 
identifying chemical warfare experts through an integrated employee information 
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profile, or pinpointing what munitions are available at any given place at any 
given moment. It will also help the Department to accomplish its primary goal to 
achieve a Clean Audit Opinion by 2007. 

The DoD Business Enterprise Architecture is just the first step on a long road to 
transformation. Results and change are often evolutionary, not revolutionary. In 
building the BEA, we are developing a Defense-wide information technology 
infrastructure that will include all appropriate system requirements associated 
with critical infrastructure protection and information assurances to ensure 
consistency with DoD's Joint Technical Architecture. The architecture is still 
evolving and will be updated continually. Further business process re- 
engineering and definition of data requirements can be expected in the future. 

Furthermore, realizing that there must be an active and implementable plan of 
action, we are taking steps to ensure that the transition plan correlates with the 
architecture and that it contains measures that help us control future investments 
in business systems, it will also encourage retirement of outdated legacy 
systems as quickly as possible. 

BMMP Accomplishments 

While we have indeed encountered challenges implementing BMMP at the 
Department, we are already seeing measurable results that have positive 
impacts on the Department’s business processes and capabilities. These 
successes include the following; 

Developed and implemented a broad-based program strategy. 

Created initial versions of a Business Enterprise Architecture (BEA) and a 
Transition Plan. 

Established a Department-wide governance structure for business 
transfonriation. 

Outlined a portfolio management process and corresponding system-assessment 
process design. 

Developed the methodology for business processes reengineering and modeling. 

Provided extensive support for business process reengineering in the target 
areas. 

Developed an initial inventory of business systems. 

Identified relevant accounting and financial rules and requirements necessary to 
correct material weaknesses in the Department’s Financial Statements and the 
corresponding financial transactions. 
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Identified the basic template for a Standard Accounting Code Structure. 
Developed the template and pro forma entries for implementation of a Standard 
General Ledger. 

Developed an initial Business Process Reference Model to use as a starting 
point for Business Process Reengineering and Modeling across the Department. 

Challenqes/Lessons Learned from the DoD BMMP Activity 

IBM is aware that adapting transformation models from the private sector to the 
Federal Government structure is not easy. At DoD, given the shared military and 
civilian leadership, the culture differences among the Services, varied 
infrastructure stages of development, existing policies and past practices, 
delivering a top-down model for implementation is formidable. The breadth, 
depth and different missions, compounded by national and international interests, 
add further complexity. There will continue to be a need for change management 
and individual Service involvement in the planning and execution stages of the 
BEA development and implementation, just as there is with other agencies, and 
in the private sector. Further, as ongoing DoD transformation activities emerge 
that must be considered and integrated into the enterprise architecture, we and 
DoD will work with all interested and affected stakeholders to receive their 
support and ideas to enhance the BEA and expand it to include all relevant 
transformation activities. 

Conclusion 


We believe the focus on Enterprise Architecture is a key process in the United 
States Government and its Agencies being able to achieve the same results. 

Total cost of ownership of providing technology is the only true measure 
important. Typical considerations exclude so-called hidden costs. Many focus 
on the highly visible cost of acquisition of hardware, software and bandwidth. In 
most industry activity based cost analysis, the human capital costs exceed the 
technology cost. Certainly that is true in many federal agencies today. 

The focus on the Enterprise Architecture process should be the basis for 
evolution from the tactical, even sub-tactical, management of technology assets 
within the Federal Government to a more strategic focus. The Federal Enterprise 
Architecture provides a foundation for governmental transformation which will 
enable agencies more effectively to accomplish their missions by strategically 
leveraging their information technology investments and operational processes. 

Thank you for the opportunity to discuss or views and experience with you. 

##### 
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Mr. Putnam. Thank you very much, Dr. Wells. 

We will begin with some questions for the entire panel, begin- 
ning with Dr. McClure. What is the Federal Government’s shining 
achievement in this area? What is the key area where we can hang 
our hat and say we have actually made some real progress here? 

Mr. McClure. Mr. Chairman, I think just looking back 5 years 
or more and seeing where we are today, despite the fact that those 
bars on those charts look dismal, we are, believe me, much further 
ahead than where we were previously. There is agreement on 
frameworks, there are a lot of available tools, we have a common 
assessment process that GAO uses that the industry and the agen- 
cies accept to a large degree, and we are seeing progress. It is, I 
think, a tough area, as Dr. Wells just said. The complexity of what 
we are doing in the public sector environment, particularly at the 
large department level, can be a little overwhelming at times. I 
think there is good news here as well in that progress is being 
made and that we do have some agencies that have done some ab- 
solutely fabulous jobs putting architectures together. 

The other shining light is the FEA. I think it represents a world- 
class view of trying to look at how government functions. And for 
the first time we have a clear picture of the real possibilities of op- 
erating government in a different way, and I think that is a very 
significant achievement. 

Mr. Putnam. Mr. Puvvada. 

Mr. PUWADA. I concur, Mr. Chairman. I think one of the biggest 
improvements that we have seen is that agencies are now begin- 
ning to think about enterprise architecture at the start of a system 
development process or the start of an investment management 
process. So from that perspective, that is a significant change in 
terms of behaviors, in terms of incentives there. There are aligning 
IT strategic plans, investment review boards, and business case 
and budget submissions. We have seen good leadership from 0MB. 
We are obviously concerned about lack of resources, as we talked 
about earlier, but this has been a priority and this is going to take 
time to get to see most agencies show up in stage 5 category, but 
we are really positive about the progress that has been made, and 
a lot of agencies are actually looking at the first thing that they 
do this transformation through architecture. 

Mr. Putnam. Mr. Lorentz, do you wish to add anything? 

Mr. Lorentz. I think the one thing that sticks with me, I didn’t 
keep track of how many times in the course of the testimony to this 
point that we have referred to this problem as a business problem, 
not a technology problem. I have to tell you 3 to 5 years ago we 
probably would not have had that conversation. That is being 
shown in significant behaviors by business leaders, deputy sec- 
retaries. Just look at the five initiative, the President’s initiatives, 
all business oriented, and E-Government enables the other four. So 
it is really the understanding that we are trying to solve a business 
problem here. 

I sometimes think back to the CTO experience. It should have 
been chief transformation officer instead of chief technology officer, 
because I would say 99 percent of the time that I spent in that po- 
sition was spent on non-technology issues. It was about business 
mission roles and outcomes. So I think the real major progress, cer- 
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tainly the FEA I happen to believe is a great “how,” but the real 
issue is mission citizen-centered real business problems. 

Mr. Putnam. War Eagle. 

Mr. Wells. War Eagle. 

I agree completely with Norm’s assessment. The change in focus 
is the correct change, that is, that we are focusing not on IT as a 
cost center; how much are you spending on X. It should be how 
much are you spending on X to improve a certain process. So this 
change in focus I think is the primary success of FEA and the en- 
terprise architecture initiative in the agencies. This is a manage- 
ment problem, it is not an IT problem. It is a management prob- 
lem, and focusing the assets strategically to be addressed to the 
mission and processes of the agency itself. 

Mr. Putnam. Well, you have used a number of examples from 
your IBM experience and you talked a little bit in your opening tes- 
timony about the scale of a department like Defense. What lessons 
can we draw from the private sector that do apply to something as 
mammoth as the Federal Government? 

Mr. Wells. The Federal Government has, as most businesses, 
historically managed information technology either tactically or 
sub-tactically. By changing to a focus of managing It as a strategic 
asset to enable the business transformation, we have discovered 
that it costs a heck of a lot less. I know agencies in town that actu- 
ally have too much money. And when you have too much money, 
you can waste it. 

IBM ran out of money in 1993, and we had to fundamentally re- 
assess our business. And so when we started managing technology, 
we took the toys away from everybody and started managing those 
toys as strategic assets. And for a technology company to take toys 
away from its employees represented a massive cultural change 
that had to be managed from the top. But when we did it, we found 
out we could consume a lot more resource, a lot more, multiples of 
what we used to consume, with fundamentally much less invest- 
ment. 

Today, the IBM Corp. has no paper processes. I could not even 
remember the last time I touched a piece of IBM business paper. 
We manage our business electronically. We have substantially re- 
duced the cost of our support staff, we have substantially increased 
our own productivity, and we are spending a heck of a lot less. It 
is a fundamental change in looking at technology as a strategic 
asset to be managed by senior management, not by the IT staff. 

Mr. Putnam. Mr. Lorentz, you are back in the private sector. 
Would you like to comment on the lessons we can pick up from the 
private sector that apply to something as large as the Federal Gov- 
ernment? 

Mr. Lorentz. Well, it is interesting. Recently I have had the op- 
portunity to talk to some private sector CEOs, and a lot of them 
are taking significant interest in the technology investment, and so 
that the CEOs are actually saying I need to understand the tech- 
nology injection because technology now is improving their product 
line and business processes. Any conversation in the boardroom 
with the CEO includes whatever the chief technology is, CIO, CTO, 
as well as the chief financial officer. So the fact that we are putting 
this construct in place in the Eederal Government will, I think as 
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a leading indicator, the leadership piece of this is a leading indica- 
tor to the progress that we can make. 

And I certainly support what Dr. Wells was saying. What has to 
show up now is consequences. Transformation does not occur with- 
out consequences. There needs to be more significant analysis done 
of the cross-agency, cross-organizational opportunities for consoli- 
dation, and then the agencies and the Federal Government need to 
go on a collaboration diet. And that means that they get the money 
to do the collaborative initiatives and they do not get the money 
to do the one-offs. And it is not a bottoms-up experience, it is a top- 
down experience. 

Mr. Putnam. When you say consequences, are funding issues the 
best consequence? 

Mr. Lorentz. Absolutely. 

Mr. Putnam. The only consequence? 

Mr. Lorentz. Yes, certainly. If you take away the resources for — 
you know, when I was in 0MB, I think at the time we did the 
grants analysis, we had 17 grants engines. OK? You can argue 
whether we need one. You can certainly believe we don’t need 17. 
And so on the face of it, it doesn’t hold water. And, by the way, 
that means we are spending an extraordinary amount of money 
doing the analysis down in the vertical and not as much money 
doing the EA FEA cross-organizational analysis. With that im- 
proved analysis and data and the engagement of the leadership, 
which would be the PMC, the deputy secretaries in those issues, 
and driving those budget conclusions, then the transformation will 
occur. 

Karen was describing earlier the areas, financial management, 
human resources and so forth, where they are doing that kind of 
analysis right now. That is where I think we have the near-term 
opportunity to exhibit that leadership. 

Mr. Putnam. Mr. Puwada would you like to comment on that 
line of questioning, the lessons learned and the consequences? 

Mr. Puwada. Digging a little bit deeper into lessons learned, 
where we find agencies succeed is where they really focus on target 
architectures. We have a hard time, a lot of times, our folks, when 
they are working with agencies, convincing agencies not to get too 
much into documenting technically, as is architecture. So in terms 
of where the Government needs to be is focused on the target ar- 
chitecture in the context of how do you improve the business and 
citizen services, as you articulated at the beginning of this hearing. 
And then taking that target architecture, because it tends to be 
conceptual because you are, again, not there in terms of implemen- 
tation, take that transition plan and talk about how that would be 
integrated into standard business processes. It is not a separate 
plan, it needs to be institutionalized. I think that is when we are 
going to really see some results. 

One of the things that is not quite evident is that the reason why 
we are not seeing results is that it is a process where we all under- 
stand now that we need to build architectures, we need to think 
architectures. Now, we are just beginning to see the results. I think 
as we see more and more of these successes, then we understand 
a little bit more about how to optimize the cycle of going forward 
in making some investment decisions as well as implementations. 
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So it is a lot of work to be done, like we talked about before, but 
I think positive incentives and focusing on the right area, not nec- 
essarily documentation for technical purposes, I think will get us 
there. 

Mr. Putnam. Dr. McClure. 

Mr. McClure. I can echo a lot of just what has been said. I 
think it all begins at the top. If you don’t have the executive com- 
mitment, or even interest in this, it is not going to be successful. 
That is certainly learned from a lesson learned. 

I think, too, disciplined processes have to be in place. Successful 
organizations, public and private, are ones that find the ways to do 
things that bring value to what they are in business for, and they 
repeat them and they institutionalize them; and that is very impor- 
tant as we move forward. The business and performance focus of 
architecture is what this is all about, and I agree totally with Norm 
that is the value that we are getting out of this right now. 

And two other lessons learned are governance and tools. Don’t 
try to do this unless you have a governance process, because we 
have spent decades of writing architectures on paper but never put- 
ting them in place or enforcing them. And the other is tools. We 
have some good tools that are available to do enterprise architec- 
ture work, but we have to have people that know how to use them. 
So getting the right skills in place, whether it is inside Government 
or through the assistance of contractors, is really key for success. 

Mr. Putnam. The contractors point is an interesting one. What 
challenges or successes or lessons learned from our contractors’ ex- 
perience can we apply to this enterprise architecture improvement 
process? They certainly have a big role to play in this. What do we 
learn from their experience? Anyone. 

Mr. PuwADA. One of the things that we have to do a better job 
of is simplifying this whole enterprise architecture and its concepts. 
Typically, we don’t do a good job of explaining what it is, to the 
point where business lines look at this stuff and say that is tech- 
nical. So we need to do a better job of articulating in very simple 
terms, very clear terms, here is how you can develop a road map 
for your business goals and business performance. 

Generally, from a contractor point of view, the biggest challenge 
out there is to find skilled enterprise architects; not just within the 
Government, even for us. It is an evolving discipline, and it re- 
quires not only technical skills, business skills, but the articulation 
of that, because you are facilitating a business transformation on 
a regular basis. So we are working hard. Member companies that 
I represent are working very hard in getting better at these skills 
so that we can support the Government. 

Mr. Putnam. This whole notion of cultural change keeps coming 
up. Everybody has mentioned it in some form or fashion. How do 
we tackle that challenge? How do we really fundamentally change 
the culture? And we will begin with Dr. Wells. 

Mr. Wells. Senior management has to provide sustained com- 
mitment. I have witnessed several attempts at transformation in 
the last few years in this community, and it is easy to get a senior 
manager to articulate the requirement for cultural change. The 
words flow easy. But then it requires changing behavior and en- 
forcing the behavioral change. And this requires somebody that is 
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going to be around for a while, going to enforce. Norm said there 
has to be consequences. There has to be consequences for not 
changing behavior. Those consequences can come from within the 
agency or they can be encouraged by the Congress. But there cer- 
tainly has to be sustained executive commitment to enforcing be- 
havioral change; otherwise, it will never happen. It cannot bubble 
up from the bottom. 

Mr. Putnam. Mr. Lorentz. 

Mr. Lorentz. Just to reinforce that, transformation does not 
come from an internal source. In the private sector it generally 
comes from a marketplace intervention: you either change your or- 
ganization or you become extinct, or you have a leader that be- 
comes unreasonable and says this is the way I am going to run the 
enterprise. So we have to figure out what that looks like in the 
Federal Government. 

Certainly the President’s management agenda, good fundamental 
blocking and tackling management practices, is an excellent start. 
We have some good codification in law, so regardless of which of 
us comes and goes, there is actually those permanent positions in 
place. We need to put people in career positions that can, for in- 
stance, the architect position and also in the agencies that can con- 
tinue to maintain the processes while the necessary leadership 
changes are occurring. 

But it really does come down to what Ray was saying. You have 
to have leadership ownership, business ownership, and there has 
to be consequences to actions. The nearest term thing to that in the 
Federal Government is certainly the budget, but also in the private 
sector there are other methods that can be used. 

Mr. Putnam. Mr. Puvvada. 

Mr. PUWADA. If you go back to the enormity of why we need the 
culture change. Government and lots of private organizations, as a 
matter of fact, have been so much used to thinking in the context 
of an organizational structure. So now what we are talking about 
is going beyond the organizational structure, so the order of mag- 
nitude of culture change that is required is enormous. It is going 
to take different steps, different stages similar to the maturity that 
has been talked about here. Norm certainly addressed the “who” 
part of it; you have to have some change agents, whether they are 
from within the Government, from outside. 

I think what will go a long way in impacting the culture change 
is really some real success stories and the eventualization of those 
success stories, and real results to go with it. So we really need to 
see results come out of this initiative and to be able to articulate 
that value in terms of business and government performance and 
relate to citizens’ expectations. So it is not an easy thing to do. Like 
Norm said, in the private sector your existence is at stake if you 
don’t change. In the Government, our security is at stake if we 
don’t change. So we have the similar challenges that the private 
sector continuously goes through, but it is going to take a long time 
for the culture change to occur. 

Mr. Putnam. Dr. McClure. 

Mr. McClure. I would agree. I think you need a combination of 
strong levers. Maybe you need a baseball bat. Some people just will 
not fall in line until there is some real pressure brought to bear. 
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But I think you have to counterbalance that. You can’t do that in 
the Government just with a forcing function. You have to 
incentivize change. And I think PV is right on target. We need to 
have some demonstrated results and we need to go evangelize 
those results and show executives who are skeptical that change 
can happen and this can make a big difference. So I think best 
practices, examples, case studies go a long way. 

And then last I think it is just dialog. It is conversation. It is 
education. It is awareness building. We have to continue to have 
this dialog with more than just the technical people in the room. 

Mr. Putnam. Is there any example that you can think of where 
an agency has done particularly well and the right people have 
evangelized it and brought about a positive change in behavior? 

Mr. McClure. I think there are examples. That is part of the 
issue, is we have examples in the Federal Government where EA 
has been used, where investment controls have been used, and 
there is just not a recognition of the value of actually talking about 
it. Sometimes there is a fear of talking about it because you don’t 
know what will come back to bite you. So it is just changing the 
culture and realizing success needs to be advertized. 

I think there are examples of cost savings and reduction in dupli- 
cative systems and actually progress in making reuse of software 
in many of our component agencies and departments. There are 
bits and pieces; they are not fully in place everywhere. So you 
might have a unit, an office, or an organization within a depart- 
ment that has done some of this, and that just doesn’t see the light 
of day. It is not big enough, the dollars are not big enough when 
you are talking about billion dollar budgets. 

Mr. Putnam. Unfortunately, we are going to have to wrap this 
panel up, but I want to give everyone the opportunity to have some 
closing remarks, so we will begin with Dr. Wells and move down 
the panel and share anything that you had hoped to have come out 
of this hearing that may not have or any thoughts or question that 
you wish you had been asked, whatever the case may be. Dr. Wells. 

Mr. Wells. I often hear in the agencies a statement that if we 
had the investment money, we would be glad to modernize our in- 
frastructure. IBM had to self-fund its transformation. It is about 
using what you have more efficiently. 

The second thing that I would conclude with is the whole notion 
of chief architect. These skills are really rare, as has been men- 
tioned, but the job is really the chief business architect. It is about 
architecting the business processes. Until you have rearchitected 
those business processes, you cannot effectively apply technology in 
a transformational manner. 

Mr. Lorentz. First of all, I thank you for having these hearings 
and staying the course and showing the interest and that kind of 
support for Karen Evans, who is there now and I was there before. 
This is really hard work. There is no aspect of the Government 
value chain that doesn’t need to be changed. In the Government 
today, pretty much everything operates vertically. That is the natu- 
ral state. And so the transformation as to horizontal and why 
should we do that is because of September 11, it is because the 
needs of the citizen are now horizontal. 
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The one thing that I would respectfully encourage you to do is 
to help with the appropriations process, because even when we did 
manage to get funding for cross-organizational analysis into bills 
and so forth, we lost that funding in the appropriations process. 
Part of that is because perhaps we weren’t as adept as we could 
have been at telling our story. But we would really solicit the help 
in making sure that the appropriations occur horizontally as well 
as vertically, because again, to reinforce, we are spending a lot of 
money on EA in the silos. If you look at the amount that we are 
spending on FEA and cross-silo analysis, it is not quite a rounding 
error. 

Thank you. 

Mr. PUWADA. I echo Norm’s sentiments and thank you very 
much for highlighting this to be a priority issue. And I think the 
whole methodology as well as the report, has significant impact on 
this, and we hope that effort certainly continues. 

If I net it down to what needs to be done going forward, if you 
really look at a couple of technical things underlying that actually 
is going to enable interagency information sharing and collabora- 
tion, the whole data architecting issue needs to be a very high pri- 
ority. And one of the impediments to people wanting to share 
across is security; do I have security, is my citizens’ privacy really 
taken care of in terms of meeting the expectations there. So if you 
couple data architecting with the baked in enterprise security ar- 
chitecture as a priority, we will begin to see some progress in that 
area, and I strongly recommend looking at that deeply and show 
your commitment as well there. 

Thank you. 

Mr. Putnam. Dr. McClure. 

Mr. McClure. I want to commend you, too, Mr. Chairman, and 
thank you for having the hearing and focusing attention on this 
topic, as complex and technical as it can get at times. 

My bottom line is, I think, as I said at the beginning of my oral 
statement, at the end of the day we have to keep our sight focused 
on what this is doing to improve the quality of government. We 
have to keep the citizen in mind and ensure that we are creating 
a more simplified and very cost-effective and efficient Government. 
That is what this all about, and we don’t want to lose sight of that. 

Second, I think we have to focus on results. We have to move be- 
yond the assessments to focusing on the “so what has happened, 
what is different” and get examples. The caveat I put on that is 
that architecture is a long-term process. It requires an up-front in- 
vestment spike. That is why you see these large dollar figures in 
terms of what agencies are spending. The returns are slower in 
coming than if you were building a simple application or a single 
purpose system. You are rearchitecting and changing and moving 
lots of pieces of organizations. But, nevertheless, I think we have 
to begin asking when those results are going to occur. We need tan- 
gible, measurable results in the areas that we have talked about 
today, and we need to hold people accountable when they are say- 
ing that those will be the actual results that the Congress and the 
American people will see. 

Mr. Putnam. Well, I want to thank all of you for your very in- 
formative and insightful testimony. I appreciate your taking the 
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time out of your schedule to be with us today. And I want to thank 
Mr. Clay for his participation in the hearing as well. 

Clearly, the proper design, development, and implementation of 
EAs across the Government has the potential to save millions in 
taxpayer dollars by eliminating redundant spending. Further, 
agencies’ EA efforts are already facilitating the transition to a more 
responsive and citizen-centric Government by improving efficiency 
and facilitating cross-agency collaboration. However, as we have 
seen, we have much work to complete before we fully realize that 
goal. OMB’s efforts in creating a common framework, the FEA, for 
achieving governmentwide development and implementation has 
already proven itself to be a valuable IT investment planning tool, 
as evidenced by the identification and creation of the Lines of Busi- 
ness initiative. While we are experiencing growing pains in inte- 
grating the agencies’ individual EAs into the FEA, I believe the ef- 
fort will lead to significant cost savings when the work is further 
advanced. 

In the event that there may be additional questions that we did 
not have time for today, the record will remain open for 2 weeks 
for submitted questions and answered. 

With that, we again appreciate your hard work, and the meeting 
stands adjourned. 

[Whereupon, at 4:55 p.m., the subcommittee was adjourned, to 
reconvene at the call of the Chair.] 

[Additional information submitted for the hearing record follows:] 
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Committee on Government Reform 

Subcommittee on Technology, Information Policy, Intergovernmental Relations, and the 

Census 

“ Federal Enterprise Architecture: A Blueprint For Improved Federal FT Investment 
Management and Cross- Agency Collaboration and Information Sharing” 

May 19, 2004 

Karen Evans Response to Questions for the Record 


For Enterprise Architecture & Planning we reported in the FY2005 
President's Budget $513.2 million and $511,43 forFY2004, 

This is the total that agencies reported in Part 3 of their exhibit 
53. It includes the following items: 

(d) Part 3. Enterprise architecture and planning. 

Report amounts for IT investments that .support strategic management 
of IT operations (e.g., business process redesign efforts that are 
not part of an individual investment or initiative, enterprise 
architecture development, capital planning and investment control 
processes, procurement management, and IT policy development and 
implementation). (Exhibit 53.8 on page 16 from last year's A-11 
guidance.) 
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